This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Direct test mode for DK nRF5340 :: Illegal value 0x21001238 written to register 66 (MSP_NS) ignored

Hi,

I am using nRF 5340DK borad, trying to flash Direct test mode sample "nordic,nrf5340-dk-nrf5340-cpunet". My aim is the enable direct test mode on the nrF board in order to test Constant tone extension features of BT 5.1 specs.

I downlaoded the direct test mode code from examples samples , it compiled successfully but when zephyr.elf file is downloaded to nRF 5340DK board it gives this error

Illegal value 0x21001238 written to register 66 (MSP_NS) ignored

Can you suggest alternative way to flash right firmware to test.

Can Nordic support team or someone please upload possibly the DTM firmware .elf or .hex or .bin file with your working setup.

Please also find attached snapshots for your reference. Can you please guide how can i get DTM on nRF 5340 or some issue in my setup will be appreciated.

thanks

Parents
  • Hi, 

    The support staff is reduced during the summer holidays, and you may experience delayed answers.

    I see the same issue on Segger, but our segger expert is on vacation. I will contact him when he is back in the office. 

    I would suggest you use west to build and program the DTM sample. You could open command prompt from the tool manager:

    Locate under  NCS\v1.6.0\nrf\samples\bluetooth\direct_test_mode and execute:

    west build -b nrf5340dk_nrf5340_cpunet && west flash --recover

    Locate under NCS\v1.6.0\nrf\samples\nrf5340\empty_app_core
    west build -b nrf5340dk_nrf5340_cpuapp && west flash --recover

    Then, you could test the DTM now. 

    -Amanda 

  • Hi Amanda,

    I tried exact steps as you mentioned and also were successfull, firstly i had to install nrf command tools and set correct environment paths manually.

    Flasing of both steps was success : attached PIC

    but still DTM commands are not working, can you help please. Are USB pins correctly configured in default project as nRF5340 DK board , can it be issue ?? How can i check

    on Board i see following

    TXD P.020 andP1.01

    RXD P.022 and P1.00

    are these pins same in the default program ?

    thanks

  • Hi, 

    There are three virtual COM ports. See Getting logging output for information about the COM terminals on which the logging output is available.

    I can see COM 47, 48, 49 for nRF5340DK, and I connect to COM 49 to get the output from the network core without modification pins in the dts,. If you are not sure which com port to use, could you try them all?  

    -Amanda H.

  • Hi Amanda,

    thanks for trial at your end.

    But i followed all steps again, success in each step, but still DTM commands not accepted by module. I see 3 ports 18,19,20, i tried on each port but no repsponse. I also tried on nRF connect (direct test mode Tool)  "please make sure device has been programmed with correct firmware" message is shown.

    I fear some thing still not configure appropriately.

    1. which baud rate you used ?

    2. can you share me your .elf file and other files which i can flash on my board?

    thanks

  • Hi Amanda,

    Good news DTM mode works now.

    I guess there is issue in the commands you provided previously,

    I tried WITHOUT --recover option, DTM commands are sent and i get proper response.

    Please let know if without --recover some issue my occur

    Altleast my setup this works:

    Locate under  NCS\v1.6.0\nrf\samples\bluetooth\direct_test_mode and execute:

    west build -b nrf5340dk_nrf5340_cpunet && west flash

    Locate under NCS\v1.6.0\nrf\samples\nrf5340\empty_app_core
    west build -b nrf5340dk_nrf5340_cpuapp && west flash

    Baud rate : 19200 for DTM command testing

  • Hi, 

    Happy to know it can work on your side. 

    The --recover command erases the flash memory and then writes a small binary into the recovered flash memory. This binary prevents the readback protection from enabling itself again after a pin reset or power cycle.

    Recovering the network core erases the flash memory of both cores. Recovering the application core erases only the flash memory of the application core. Therefore, you must recover the network core first. Otherwise, if you recover the application core first and the network core last, the binary written to the application core is deleted and readback protection is enabled again after a reset.

    -Amanda H.

Reply
  • Hi, 

    Happy to know it can work on your side. 

    The --recover command erases the flash memory and then writes a small binary into the recovered flash memory. This binary prevents the readback protection from enabling itself again after a pin reset or power cycle.

    Recovering the network core erases the flash memory of both cores. Recovering the application core erases only the flash memory of the application core. Therefore, you must recover the network core first. Otherwise, if you recover the application core first and the network core last, the binary written to the application core is deleted and readback protection is enabled again after a reset.

    -Amanda H.

Children
Related