• State Not Answered
  • Replies 24 replies
  • Subscribers 69 subscribers
  • Views 4782 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287725
Options

nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER

Hello Team,

We are interfacing nRF52832 with an external flash for data storage. Could you please point to the right document/link/code reference on how to interface external flash (on SPI) with nRF52832 on nRF Connect SDK 1.8.0?

Thanks!

  • 0

    Hi Hakon,

    Thanks for keeping a tab on this. 

    Few points to consider:

    1. I tried with slower speed 1M, and it didn't help. Our routing is not so long, Flash is right next to the BLE module.
    2. I checked the datasheet of Flash and I believe the parameters in overlay are correct. Also, it works always when I reset the board using the reset button on the board.
    3. The issue is I see this error, whenever I program it using JTAG and JTAG resets the board, it doesn't detect the SPI. Also, if I disconnect the power of the board and reconnect it, first time, I see the similar issue. After pressing reset button on board, it works.

    Not sure what's going on here.

    Is there a way we can init the external lash at run time (not from the overlay)? I may be reiterating but our usecase is to use external flash for OTA purpose.

    Thanks!

  • 0 in reply to embeddedER

    Hi,

     

    embeddedER said:
    The issue is I see this error, whenever I program it using JTAG and JTAG resets the board, it doesn't detect the SPI. Also, if I disconnect the power of the board and reconnect it, first time, I see the similar issue. After pressing reset button on board, it works.

    thank you for clarifying!

    Q1: Could you confirm if another debug reset puts the device into a good state? If yes, I think I have an idea on what can have happened here.

    Q2: Could you try to run this command before flashing the device to see if the issue still appears?

    nrfjprog -e

    This will erase the nRF first.

     

    If the device now behaves normal after initial programming, I believe it can be related to a reset before flashing the new program. If your old program is also present in flash, it will boot up for a small period of time and can leave the SPI-NOR flash in a mid-sequence operation before the nRF is re-flashed.

     

    Kind regards,

    Håkon

  • 0

    Hi Hakon,

    1. I tried with erase and flash, but it didn't help.

    2. I tried with Ozone debugger (Run program in debug mode from Ozone) and it detects Flash chip every time. No error message (E: Device id 00 00 00 does not match config ef 40 14). However, I think this behavior is same as pressing Reset button on our board and it works with that too.

    Issue is when I connect the power for the first time with the board (same as when I program the board using JTAG). Unless I press the reset button, it doesn't detect 

    I also tried one more thing: reboot the board using sys_reboot(SYS_REBOOT_COLD/WARM) after failing to get the Flash device binding. With this, after cold/warm boot, Flash chip is detected. First cycle after flash fails, but all cycles after sys_reboot are OK.

    Is there a way we can try initializing the Flash device at the run time? Probably mimic what's happening during the boot time (using overlay content)?

    Any other suggestions?

    Thanks!

  • 0 in reply to embeddedER

    Hi,

     

    embeddedER said:
    2. I tried with Ozone debugger (Run program in debug mode from Ozone) and it detects Flash chip every time. No error message (E: Device id 00 00 00 does not match config ef 40 14). However, I think this behavior is same as pressing Reset button on our board and it works with that too.

    Resetting and running in vscode should yield the same behavior as with Ozone. This seems strange to me that it only shows itself when you're using the cortex m debug in vscode, which leads me to think that there's something in the way that the plugin itself works that is causing the behavior.

    In VScode, when entering debug mode, you should see this appearing:

    If you click this image:

    It should reset the target and run to main().

    Could you confirm if the readout still fails even after a reset in the debugger?

    Could you also share the debug console output?

    embeddedER said:
    Is there a way we can try initializing the Flash device at the run time? Probably mimic what's happening during the boot time (using overlay content)?

    It is not an easy method to change the ordering, as the spi-nor is initialized before main in reached.

     

    Kind regards,

    Håkon

  • 0

    Hi Hakon,

    I tried what you suggested and here is the outcome:

    1. Erase and Flash the board using VS Code. ==> Flash chip not detected (E: Device id 00 00 00 does not match config ef 40 14) and device get for Flash failed
    2. Start the debug using VS Code. ==> Flash chip detected and I am able to get the device binding and do erase oeration on Flash chip.
      1. Logs: 
        Reading symbols from c:\Users\ncs\v1.8.0\toolchain\opt\bin\arm-none-eabi-objdump.exe --syms -C -h -w c:\Users\Documents\Work\build\zephyr\zephyr.hex
Reading symbols from c:/users\ncs\v1.8.0\toolchain\opt\bin\arm-none-eabi-nm.exe --defined-only -S -l -C -p c:\Users\Documents\Work\build\zephyr\zephyr.hex
Launching GDB: "c:\\Users\\ncs\\v1.8.0\\toolchain\\opt\\bin\\arm-none-eabi-gdb.exe" -q --interpreter=mi2 "c:\\Users\\Documents\\\Work\\build\\zephyr\\zephyr.hex"
    Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems
Launching gdb-server: "C:\\Program Files\\SEGGER\\JLink\\JLinkGDBServerCL.exe" -singlerun -nogui -if swd -port 50007 -swoport 50008 -telnetport 50009 -device nRF52832_xxAA -select usb=601005338 -rtos "C:\\Program Files\\SEGGER\\JLink\\GDBServer\\RTOSPlugin_Zephyr.dll"
    Please check TERMINAL tab (gdb-server) for output from C:\Program Files\SEGGER\JLink\JLinkGDBServerCL.exe
Finished reading symbols from nm: Time: 186 ms
Finished reading symbols from objdump: Time: 234 ms
Reading symbols from c:\Users\Documents\Work\build\zephyr\zephyr.hex...
(No debugging symbols found in c:\Users\Documents\Work\build\zephyr\zephyr.hex)
WARNING: Cortex-Debug will deprecate use of GDB version 8 after July 2022. Please upgrade to version 9+
0x0001999e in ?? ()
Program stopped, probably due to a reset and/or halt issued by debugger
add symbol table from file "c:/Users/Documents/Work/build/zephyr/zephyr.elf"
(y or n) [answered Y; input not from terminal]
Reading symbols from c:/Users/Documents/Work/build/zephyr/zephyr.elf...
Resetting target
Resetting target
[New Thread 536881256]
[New Thread 536881008]
[New Thread 536880760]
[New Thread 536881504]
[Switching to Thread 536881256]

Thread 2 hit Temporary breakpoint 1, main () at ../src/main.c:24
24	{
    3. Press Reset button on Debug Console. ==> Flash chip detected and I am able to get the device binding and do erase operation on Flash chip.
      1. Logs: 
        [New Thread 536878976]
[New Thread 536878728]
[New Thread 536878480]
[New Thread 536880512]

Thread
3 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 536881008]
?? () at C:/Users/ncs/v1.8.0/zephyr/arch/arm/core/aarch32\cpu_idle.S:107
107		cpsie	i
Resetting target
[Switching to Thread 536881256]

Thread 2 hit Temporary breakpoint 2, main () at ../src/main.c:24
24	{

    So, it seems it doesn't work when we Flash the board for the first time and also when we connect power to the board for the first time. After that it works always.

    Thanks!

Related