Flash programming on Renesas DA14706 seems to leave the flash controller in an invalid state

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Flash programming on Renesas DA14706 seems to leave the flash controller in an invalid state

      Hello,

      When I use J-Link commander to write a binary to the flash using the J-Link OB on the evaluation board, the SoC will then not boot and following the execution in Ozone shows that it stays in the boot ROM for a while and then reset.

      I noticed that if I run any example program from the Renesas SDK from RAM using their IDE, the flashed binary will then boot without issues. I dug through the init code of the SDK and found that the function that configure the flash controller (on this SoC the flash is external so different modules may be used and depending on the CPU clock speed some settings may need to be changed, so there is a function for that) allows the SoC to boot again.

      I took note of all the writes the SDK was performing from this function and replicated them using J-Link Commander and it worked ! Here is the script:

      Source Code

      1. // The lowest serial number is the M33 core
      2. device DA14706
      3. // Select the single wire debug interface. JTAG is not present
      4. si SWD
      5. // Max supported speed
      6. speed 4000
      7. connect
      9. //exec EnableEraseAllFlashBanks
      10. //erase
      11. loadfile test_fw_image.bin 0x38000000
      13. sleep 100
      14. // oqspi_enter_manual_access_mode
      15. // OQSPIF_CTRLMODE_REG -> Manual access mode (lsb bit to zero, the rest taken from ozone)
      16. W4 0x36000004 0xF8018F82
      18. // -> oqspi_flash_exit_continuous_mode
      19. // OQSPIF_CTRLBUS_REG -> chip select enable
      20. W4 0x36000000 0x10
      21. sleep 200
      22. // OQSPIF_WRITEDATA_REG -> OQSPI_EXIT_CONTINUOUS_MODE_WORD
      23. W4 0x36000018 0xffffffff
      24. // OQSPIF_CTRLBUS_REG -> chip select disable
      25. W4 0x36000000 0x20
      26. sleep 100
      29. // oqspi_set_manual_access_bus_mode(SINGLE, true)
      30. // -> hw_oqspi_set_manual_access_bus_mode(SINGLE)
      31. // OQSPIF_CTRLBUS_REG -> Set single mode
      32. W4 0x36000000 0x1
      33. sleep 100
      34. // -> hw_oqspi_set_io(SINGLE)
      35. // OQSPIF_CTRLMODE_REG
      36. // SET OSPIC_IO2/3_OEN and OSPIC_IO2/3_DAT
      37. // also disable OSPIC_IO_UH_OEN
      38. W4 0x36000004 0xF0018FBE
      39. sleep 100
      42. // oqspi_mx25u6432_enable_quad_mode
      43. // OQSPIF_CTRLBUS_REG -> chip select enable
      44. W4 0x36000000 0x10
      45. sleep 200
      46. // OQSPIF_WRITEDATA_REG -> Write enable latch opcode
      47. W1 0x36000018 0x6
      48. // OQSPIF_CTRLBUS_REG -> chip select disable
      49. W4 0x36000000 0x20
      50. sleep 100
      52. // OQSPIF_CTRLBUS_REG -> chip select enable
      53. W4 0x36000000 0x10
      54. // OQSPIF_WRITEDATA_REG -> OQSPI_WRITE_STATUS_REG_OPCODE
      55. W1 0x36000018 0x1
      56. sleep 20
      57. // OQSPIF_WRITEDATA_REG -> 0x<config_reg><status reg> (one byte each)
      58. // status reg = OQSPI_MACRONIX_QUAD_STATUS_REG_QUAD_ENABLE_MASK
      59. // config reg = default dummy cycles and drive strength config (MX25U6432F datasheet)
      60. W2 0x36000018 0x0740
      61. sleep 100
      62. // OQSPIF_CTRLBUS_REG -> chip select disable
      63. W4 0x36000000 0x20
      64. sleep 100
      66. // Reset using pin. There is one on the board and that's the only one that work to get the card to boot
      67. RSetType 2
      68. ResetX 500
      69. go
      71. q
      Display All

      If I understood the documentation right, this SoC should be able to be able to read the first sectors of the flash to configure itself for fast XiP mode (lpccs-docs.renesas.com/um-b-15…html#da1470x-flash-layout -> product header). I tried to configure the flash controller in single spi mode to use this mechanism to no avail, only quad spi (as in the code snippet above) seems to do the trick. I also did not try to optimize the script, I really emulated what the SDK functions did.

      I'm not sure if the bug is in J-Link or Renesas and if it can be fixed, but if this workaround can save some poor soul some time that's already worth it :)

      I'm using J-Link V7.98d and SDK-10.2.6.49 on MacOS. The problem was already present in J-Link V7.96b.