osdp control_panel example not work with sdk V2.8.0

Hi,

I used the nRF52840 board with SDK v2.8.0.

When we tried to build this example code, we encountered the following error:

v2.8.0/zephyr/include/zephyr/device.h:92:41: error: '__device_dts_ord_DT_CHOSEN_zephyr_osdp_uart_ORD' undeclared (first use in this function)
92 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)

Parents
  • Hi,

    Could you send me a link or point to the location of this sample?

    Kind regards,
    Andreas

  • Hi,

    v2.8.0/zephyr/samples/subsys/mgmt/osdp/control_panel/src/main.c

  • Hi,

    Sorry by mistake *** Booting nRF Connect SDK v2.5.1 *** pest in this file.

  • ChiragBhavsar said:
    Sorry by mistake *** Booting nRF Connect SDK v2.5.1 *** pest in this file.

    I'm sorry, I don't understand this. Could you expand upon what is causing this?

    Kind regards,
    Andreas

  • Hi,

    Below is the new log for the OSDP,please check that we receive the card data without encryption.

    [00:00:00.249,603] <inf> osdp: OSDP init okay!
    17:03:26.434 -> *** Booting nRF Connect SDK v2.8.0-a2386bfc8401 ***
    17:03:26.434 -> *** Using Zephyr OS v3.7.99-0bc3393fb112 ***
    17:03:26.933 -> [00:00:00.500,213] <dbg> osdp: cp_send_command: bytes sent
    17:03:26.933 -> [00:00:00.500,274] <dbg> osdp: osdp_dump: ⸮k
    17:03:26.933 ->                                ff 53 7e 09 00 05 61 00  cf 94                   |.S~...a. ..      
    17:03:26.966 -> [00:00:00.550,384] <dbg> osdp: cp_process_reply: bytes received
    17:03:26.966 -> [00:00:00.550,415] <dbg> osdp: osdp_dump: ⸮k
    17:03:26.966 ->                                ff 53 fe 14 00 05 45 00  06 8e 01 01 b2 54 80 29 |.S....E. .....T.)
    17:03:26.966 ->                                05 51 00 0a db                                   |.Q...            
    17:03:26.999 -> [00:00:00.550,415] <dbg> osdp: cp_decode_response: CMD(61) REPLY(45)
    17:03:26.999 -> [00:00:00.650,634] <dbg> osdp: cp_send_command: bytes sent
    17:03:26.999 -> [00:00:00.650,665] <dbg> osdp: osdp_dump: ⸮k
    17:03:26.999 ->                                ff 53 7e 09 00 06 62 00  cc 98                   |.S~...b. ..      
    17:03:27.032 -> [00:00:00.700,805] <dbg> osdp: cp_process_reply: bytes received
    17:03:27.032 -> [00:00:00.700,836] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.032 ->                                ff 53 fe 35 00 06 46 01  00 00 02 00 00 03 01 00 |.S.5..F. ........
    17:03:27.032 ->                                04 04 01 05 02 01 06 00  00 07 00 00 08 01 00 09 |........ ........
    17:03:27.065 ->                                01 01 0a                                         |...              
    17:03:27.065 -> [00:00:00.750,946] <dbg> osdp: cp_process_reply: bytes received
    17:03:27.099 -> [00:00:00.750,976] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.099 ->                                ff 53 fe 35 00 06 46 01  00 00 02 00 00 03 01 00 |.S.5..F. ........
    17:03:27.099 ->                                04 04 01 05 02 01 06 00  00 07 00 00 08 01 00 09 |........ ........
    17:03:27.099 ->                                01 01 0a 92 03 0b 92 03  0c 00 00 0e 00 00 0f 00 |........ ........
    17:03:27.132 ->                                00 10 01 00 09 b3                                |......           
    17:03:27.132 -> [00:00:00.751,007] <dbg> osdp: cp_decode_response: CMD(62) REPLY(46)
    17:03:27.132 -> [00:00:00.901,428] <dbg> osdp: cp_send_command: bytes sent
    17:03:27.132 -> [00:00:00.901,458] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.132 ->                                ff 53 7e 13 00 0f 03 11  01 76 1d f7 7a 36 dd 88 |.S~..... .v..z6..
    17:03:27.165 ->                                e2 43 ba f4                                      |.C..             
    17:03:27.597 -> [00:00:01.051,788] <dbg> osdp: cp_process_reply: bytes received
    17:03:27.597 -> [00:00:01.051,818] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.597 ->                                ff 53 fe 2b 00 0f 03 12  01 76 00 06 8e 01 01 54 |.S.+.... .v.....T
    17:03:27.597 ->                                80 29 9e c0 aa fc c7 a5  57 00 ea                |.)...... W..     
    17:03:27.631 -> [00:00:01.101,928] <dbg> osdp: cp_process_reply: bytes received
    17:03:27.631 -> [00:00:01.101,959] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.631 ->                                ff 53 fe 2b 00 0f 03 12  01 76 00 06 8e 01 01 54 |.S.+.... .v.....T
    17:03:27.631 ->                                80 29 9e c0 aa fc c7 a5  57 00 ea 62 7b 12 81 a1 |.)...... W..b{...
    17:03:27.631 ->                                43 cf ba e9 57 39 2d 19  45 36 a3 d1             |C...W9-. E6..    
    17:03:27.664 -> [00:00:01.103,118] <dbg> osdp: cp_decode_response: CMD(76) REPLY(76)
    17:03:27.664 -> [00:00:01.203,430] <dbg> osdp: cp_send_command: bytes sent
    17:03:27.664 -> [00:00:01.203,460] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.664 ->                                ff 53 7e 1b 00 0d 03 13  01 77 9a dc b8 8d 13 58 |.S~..... .w.....X
    17:03:27.697 ->                                ec 40 24 7f 92 7c bf c2  04 0c 6a 87             |.@$..|.. ..j.    
    17:03:27.697 -> [00:00:01.353,759] <dbg> osdp: cp_process_reply: bytes received
    17:03:27.697 -> [00:00:01.353,790] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.697 ->                                ff 53 fe 1b 00 0d 03 14  01 78 4c 51 57 2e 27 b0 |.S...... .xLQW.'.
    17:03:27.697 ->                                8e b9 93 bb 22 25 09 f5                          |...."%..         
    17:03:27.730 -> [00:00:01.403,900] <dbg> osdp: cp_process_reply: bytes received
    17:03:27.730 -> [00:00:01.403,930] <dbg> osdp: osdp_dump: ⸮k
    17:03:27.730 ->                                ff 53 fe 1b 00 0d 03 14  01 78 4c 51 57 2e 27 b0 |.S...... .xLQW.'.
    17:03:27.730 ->                                8e b9 93 bb 22 25 09 f5  2f 45 91 ac             |...."%.. /E..    
    17:03:27.774 -> [00:00:01.403,961] <dbg> osdp: cp_decode_response: CMD(77) REPLY(78)
    17:03:27.774 -> [00:00:01.454,040] <inf> osdp: SC Active
    17:03:49.097 -> CP PD[0] card read - fmt: 1 len: 26 card_data: [ 0x32 0x40 0x4a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe5 0x58 0x00 0x00 0x21 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ]
    17:05:37.030 -> CP PD[0] card read - fmt: 1 len: 26 card_data: [ 0x32 0x40 0x46 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe5 0x58 0x00 0x00 0x21 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ]
    
    


  • Hi,

    ChiragBhavsar said:
    please check that we receive the card data without encryption.

    Have you checked if the sample enables encryption? The documentation only states that OSDP supports encryption, and nothing more.

    Kind regards,
    Andreas

  • Hi,

    can you please suggest how i can check that encryption is enable?

Reply Children
  • Hi,

    Of course. Typically you can see this in the configuration files and/or in the generated .config which you can find inside your build-folder.

    In the configuration files you can see what has been enabled or not. All I can see from the prj.conf is that CONFIG_ENTROPY_GENERATOR is enabled, but going back to the sample. 

    I'm also curious, how do you see that it is without encryption? What would you expect the output to be? I need you to expand on this, since this is a non-Nordic solution in the Zephyr part of our SDK meaning that you need to ask the OSDP and/or Zephyr forums for information about how this standard works and how the sample should behave, since this is not something that we've written and don't know it works behind the scenes.

    I'm sorry for not being able to help you further, but as mentioned OSDP is a third party solution so you need to ask the authors if you need answers for how it works. I can help you with Nordic-related issues w.r.t the sample.

    Kind regards,
    Andreas

  • Hi,

    thanks for your support,

    Can you please share the Zephyr forums link so I can ask a question related to the OSDP driver?

Related