[SOLVED] 'program 1 over 0' error on single step

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

  • [SOLVED] 'program 1 over 0' error on single step

    I'm experiencing a similar issue as described here J-Link Programming Failed messages and was hoping to see a resolution-

    I am able to download and run my application in external flash. After reaching a breakpoint, I can single-step 2 or 3 times before JLink errors out with a 'program 1 over 0' message-Are there any suggestions as to what the cause might be?

    (Unfortunately, I appear not to be able to force the use of my limited number of hard breakpoints, maybe because I am using CFI flash...)

    Thanks
    David
  • Hello David,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Could you provide a screenshot of the exact error message? Generally the error means that the Flashloader tried to program a 1 where already a 0 was. This indicates that after erasing the Flash did not work correctly as instead of the erase value being 0xFF it was 0x0 at that spot at least.

    As this issue is not related to Ozone we will move this thread to he J-Link forum.

    Also please always try to include as much information about your setup as possible, as other users that might not have the same information about prior correspondence as we do.
    IIRC your setup was a STM32F target device where the boot sequence is Bootloader->App1->App2 where App1 and App2 are running from external CFI Flash that you init via a JLinkScript and in the bootloader.
    Ist that correct?

    Best regards,
    Nino
    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.
  • Hi Nino


    I have attached a Jlink logfile indicating an instance of this.


    Some background:
    My setup is that I am using a Kinetis K60 MCU with an external flash bank. I have a bootloader which runs in internal flash, performing the low-level configuration of the MCU and peripheral devices and then jumps to the first of two applications in external flash (app1 and app2)

    Having tried a number of approaches in order to be able to debug the ext. flash applications app1 and/or app2, the problem always appears when Jlink attempts to access the external flash once debugging is underway, and reports 'Could not find CFI compliant flash device' or 'program 1 over 0' message (note that both messages appear in the attached file). I have simplified the approach here such that Ozone is configured to download the bootloader, execute it and on completion, download a simple hex file into external flash. It is here that Jlink has difficulty. I believe that once I am able to get Jlink writing to external flash after the bootloader has configured the target, all will be well.


    It's entirely possible that the bootloader's configuration of the target (although working pefectly for app1 and app2), is somehow leaving the target such that Jlink is unable to read/write the external flash-it would be helpful to know if the logfile supports this theory.


    Many thanks
    David
    Files
  • Hi Nino

    It's okay- I think the issue is with the Freescale LMEM cache block-If I disable caching in the bootloader, it look like I'm at last able to step and debug as expected in ext.flash (so far, so good anyway...)

    If this is the cause, I'd really like to understand why this prevents Jlink from working...?

    Update: I've just found this post which appears to address exactly this issue:
    [SOLVED] DEBUGGING doesn't work in external RAM, but in internal RAM

    Has the long-term fix mentioned here been implemented?


    David

    The post was edited 1 time, last by dnfuss ().

  • Hello David,

    The linker thread talks about a completely different setup so these two issues are not comparable.
    For the iMX the fix is implemented. However this will not work for all >10000 devices that we support as it is a target specific implementation each time.

    It is impossible to maintain automatic handling of this for all devices that we support.
    That is why it is user responsibility to handle cached memory sections.

    Best regards,
    Nino
    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.