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:
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.
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
- // The lowest serial number is the M33 core
- device DA14706
- // Select the single wire debug interface. JTAG is not present
- si SWD
- // Max supported speed
- speed 4000
- connect
- //exec EnableEraseAllFlashBanks
- //erase
- loadfile test_fw_image.bin 0x38000000
- sleep 100
- // oqspi_enter_manual_access_mode
- // OQSPIF_CTRLMODE_REG -> Manual access mode (lsb bit to zero, the rest taken from ozone)
- W4 0x36000004 0xF8018F82
- // -> oqspi_flash_exit_continuous_mode
- // OQSPIF_CTRLBUS_REG -> chip select enable
- W4 0x36000000 0x10
- sleep 200
- // OQSPIF_WRITEDATA_REG -> OQSPI_EXIT_CONTINUOUS_MODE_WORD
- W4 0x36000018 0xffffffff
- // OQSPIF_CTRLBUS_REG -> chip select disable
- W4 0x36000000 0x20
- sleep 100
- // oqspi_set_manual_access_bus_mode(SINGLE, true)
- // -> hw_oqspi_set_manual_access_bus_mode(SINGLE)
- // OQSPIF_CTRLBUS_REG -> Set single mode
- W4 0x36000000 0x1
- sleep 100
- // -> hw_oqspi_set_io(SINGLE)
- // OQSPIF_CTRLMODE_REG
- // SET OSPIC_IO2/3_OEN and OSPIC_IO2/3_DAT
- // also disable OSPIC_IO_UH_OEN
- W4 0x36000004 0xF0018FBE
- sleep 100
- // oqspi_mx25u6432_enable_quad_mode
- // OQSPIF_CTRLBUS_REG -> chip select enable
- W4 0x36000000 0x10
- sleep 200
- // OQSPIF_WRITEDATA_REG -> Write enable latch opcode
- W1 0x36000018 0x6
- // OQSPIF_CTRLBUS_REG -> chip select disable
- W4 0x36000000 0x20
- sleep 100
- // OQSPIF_CTRLBUS_REG -> chip select enable
- W4 0x36000000 0x10
- // OQSPIF_WRITEDATA_REG -> OQSPI_WRITE_STATUS_REG_OPCODE
- W1 0x36000018 0x1
- sleep 20
- // OQSPIF_WRITEDATA_REG -> 0x<config_reg><status reg> (one byte each)
- // status reg = OQSPI_MACRONIX_QUAD_STATUS_REG_QUAD_ENABLE_MASK
- // config reg = default dummy cycles and drive strength config (MX25U6432F datasheet)
- W2 0x36000018 0x0740
- sleep 100
- // OQSPIF_CTRLBUS_REG -> chip select disable
- W4 0x36000000 0x20
- sleep 100
- // Reset using pin. There is one on the board and that's the only one that work to get the card to boot
- RSetType 2
- ResetX 500
- go
- q
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
![:)](https://forum.segger.com/wcf/images/smilies/smile.png)
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.