Possible bug in L1 / L2 verification or RP2040_M0_0

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

    • Possible bug in L1 / L2 verification or RP2040_M0_0

      I've run into a issue where flashing / debugging the RP2040 chip is not possible if the attached flash chip is larger than 16MB. If I manually connect to the device using J-Link commander, and then disable L1 & L2 verification via the web control panel, I am able to successfully flash the chip.
      But if I try and flash / debug through ozone, embedded studio, or J-Link GDB server, sectors are erased properly, but the data does not get written properly. Unfortunately, I have not found a way to disable L1 or L2 verification other than the control panel, so I am unable to use the probe to debug at this time.
      If anyone has any information about workarounds, or needs more information, please let me know. Here is my current setup:

      J-Link Version: 7.94h
      Flash chip: W25Q512JV (a supported chip)
      MCU: RP2040
      Probe: J-Link mini EDU
      Images

      • Screenshot from 2024-02-16 15-25-52.png

        73.33 kB, 682×270, viewed 42 times

      • Screenshot from 2024-02-16 15-29-10.png

        19.62 kB, 780×253, viewed 41 times

    • After more investigation into this, I would say there is definitely an error; possibly with the RP2040 flash loader but as I don't have access to the DSK, I cannot tell. The RP2040 IS capable of using more than 16MB of flash memory. Perhaps the error was made due to misinterpretation of the datasheet; XIP, not the chip itself, is only able to use 16MB.

      Anyways, as a complete hack of a workaround, you can change any of the web commander parameters by sending post requests via curl or wget. To determine the request parameters, you can use firefox, right click to inspect page source, click the Network Tab, and then the request tab.

      Source Code

      1. curl -d"SETTINGS_comboBoxFlashDLCompareType=0&SETTINGS_ChkBoxDisableL1Verify=1&SETTINGS_ComboBoxFlashDLVerifyType=0" -X post localhost:19080/settings.htm > /dev/null --silent



      Because JLinkGDBServer does not have any ability to disable L1 verification, I created a shell script that starts the GDB server, polls web commander until it returns a 200 status code (http for OK), and then disables L1. For extra credit, symlink the script to your /usr/bin folder, chmod it to be executable, and then call it instead of JLinkGDBServer. Note that the polling portion of the script must come before JLinkGDBServer; otherwise polling will be blocked.

      Shell-Script

      1. #!/bin/bash
      3. settingsUrl=localhost:19080/settings.htm
      4. settings="SETTINGS_comboBoxFlashDLCompareType=0&SETTINGS_ChkBoxDisableL1Verify=1&SETTINGS_ComboBoxFlashDLVerifyType=0&SETTINGS_RadioBtnFlashBPOnOff=1"
      5. gdbSettings="-device RP2040_M0_0 -endian little -if SWD -speed 4000 -LocalhostOnly -nologtofile -port 2331 -SWOPort 2332 -TelnetPort 2333"
      7. {
      8. statusCode=0
      9. while [ $statusCode != "200" ]
      10. do
      11. statusCode=$(curl -s -o /dev/null -I -w "%{http_code}" $settingsUrl)
      12. done
      13. sleep 0.05
      14. curl -d"$settings" -X post $settingsUrl > /dev/null --silent
      15. }&
      17. JLinkGDBServer $gdbSettings
      Display All


      Even with all of this work though, I am still not able to set more than 4 break points (limitation of the hardware). The JLink code that uploads additional flash break points seems to ignore the settings in the web control panel and fails due to a "block verification error".

    • Hi,

      If the memory-mapped region supports max. 16 MB, this is what your flash loader does support as well.
      All our flash loaders support max. what is mapped in the address space of the MCU.
      So what you describe is not a bug and no, we have not “misinterpreted” the datasheet.
      If flashing beyond 16 MB on this MCU somewhat / half-way works, consider yourself lucky but don’t rely on it.

      If you want to have support for space beyond that (which is not XIP and therefore not “directly” debuggable anyhow), you are free to write your own flash loader:
      wiki.segger.com/SEGGER_Flash_Loader

      Disabling L1 verify can be done outside the control panel via command strings:
      wiki.segger.com/J-Link_Command_Strings
      However, the needed command string is currently not documented (we will consider to change that in the near future)
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • I disagree that this is not a bug for the following reasons:

      1. I am not flashing or debugging beyond the memory mapped space; anything above the map is for persistent storage only and does not interact with the JLink.

      2. Your provided RP2040 examples do not work with the larger flash chip; these also are not going beyond the memory mapped space.

      3. Your RP2040_M0_0 device specifies a flash size of 64MB, which is what I selected for my hardware.

      4. I don’t see how a verification process, which I presume is a read-only operation, should affect what is written to a memory mapped region.

      Thanks for the response as well as information about the command string; is the string something you are able to share?

    • Agree or not, your choice.
      Fact is:
      All J-Link flash loaders are designed to work with the natively memory-mapped space of the chip.
      For the RP2040 this is 16 MB, according to the datasheet. This means, J-Link will be able to program & verify 16 MB of QSPI reliably.

      Moving the 16 MB “window” to another portion of the flash (so effectively configure the QSPI controller to use fixed high-bits != 0 during memory mapped accesses) is not supported and there is no plan to do so. (Even though it would be technically possible)
      Again, you are free to write your own flash loader that does so.

      If we list the memory-mapped QSPI area as 64 MB while it is only 16 MB of continuous space in the datasheet, this is a bug in our software and will be corrected to 16 MB, to be in line with the datasheet.

      command string: Will take a few days to make it in the wiki but not really a secret.
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • I guess it doesn't really matter once L1 verification can be disabled, but I am not attempting to do anything different at all between the two chips.

      I am simply trying to flash the exact same code, to the exact same address (0x10000000 memory map, 0x00 flash address), in the exact same way on both chips. But when I am using a chip larger than 16MB, the JLink is not allowing me to write anything at all to the
      first 16 MB of the larger flash chip. Should I not able to flash the first 16MB of the larger chip?

      But anyways, sounds good about the wiki.

    • SEGGER - Alex wrote:

      Agree or not, your choice.
      Fact is:
      All J-Link flash loaders are designed to work with the natively memory-mapped space of the chip.
      For the RP2040 this is 16 MB, according to the datasheet. This means, J-Link will be able to program & verify 16 MB of QSPI reliably.

      Moving the 16 MB “window” to another portion of the flash (so effectively configure the QSPI controller to use fixed high-bits != 0 during memory mapped accesses) is not supported and there is no plan to do so. (Even though it would be technically possible)
      Again, you are free to write your own flash loader that does so.

      If we list the memory-mapped QSPI area as 64 MB while it is only 16 MB of continuous space in the datasheet, this is a bug in our software and will be corrected to 16 MB, to be in line with the datasheet.

      command string: Will take a few days to make it in the wiki but not really a secret.
      Are there any updates on the wiki?