• Locked Locked
  • Replies 5 replies
  • Subscribers 119 subscribers
  • Views 5753 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Debugging Cortex M3 from external Flash

Prasad Prasad
Note: This was originally posted on 12th January 2010 at http://forums.arm.com

Hello,

I am using the STM32F103 controller from ST having the cortex M3 core. My firmware mechanism demands some portion of code to be executed from external Flash memory.

While executing the firmware from external memory I could not put the hard breakpoints.

1. Is this a limitation of Cortex - M3 core or the controller?  
2. Can this be overcome by using any other tool then J-Link?
3. If this is a limitation of core the please let me know if you have any suggestions or workarounds.

Thanks,
Prasad
  • Note: This was originally posted on 13th January 2010 at http://forums.arm.com

    Hello,

    Thanks for the suggestions.

    Out of the suggested options first ('If possible, relocate your external flash to below 0x20000000') is not possible because code won't fit in available internal flash area.

    Second option 'replace the flash device with a RAM device during debug' : How this will help to place the break points as RAM will still be mapped out of '0x0 - 0x1FFFFFFF' area? External flash uses the FSMC bank1 area (0x6400 0000 - 0x67FF FFFF).

    Third option 'alternatively, use a PC based watchpoint match to halt' : How can use the PC based watchpoints? Any reference link to understand this concept?

    Currently I am using 'asm ("BKPT xxx");'  instruction to place a break point at respective point but it is very much time consuming.

    Regards,
    Prasad
  • Note: This was originally posted on 13th January 2010 at http://forums.arm.com

    Thanks for the reply. I'll try to work on the suggestions by you. Btw, I am using IAR Jlink for my debugging. Please let me know if you have any specific suggestions.
  • Note: This was originally posted on 14th January 2010 at http://forums.arm.com

    Hello,

    I evaluated the first option to map the FSMC external interface in 0x0 - 0x1FFFFFFF region but it is totally ruled out by ST. ("Memory map for CortexM3 is fixed and cannot be remapped.")

    I am working on second option but I am not sure how it will workout.

    Mean while please let me know if you have any specific suggestion for working with IAR Jlink + STM32F103ZET controller.

    Thank you very much for the support.

    Regards,
    Prasad
  • Arm Employee Badge
    Note: This was originally posted on 12th January 2010 at http://forums.arm.com

    The Cortex-M3 hardware breakpoint unit only functions in the address range 0x0 - 0x1FFFFFFF.
    Instruction space above 0x20000000 is typically writable, with breakpoints implemented via software means.

    Three options probably exist:

    - If possible, relocate your external flash to below 0x20000000,
    - alternatively, replace the flash device with a RAM device during debug,
    - alternatively, use a PC based watchpoint match to halt.

    hth
    s.
  • Arm Employee Badge
    Note: This was originally posted on 13th January 2010 at http://forums.arm.com

    Out of the suggested options first ('If possible, relocate your external flash to below 0x20000000') is not possible because code won't fit in available internal flash area.


    That's 512MB of space, this issue is more whether its possible to map the FSMC external interface in this region.

    Second option 'replace the flash device with a RAM device during debug' : How this will help to place the break points as RAM will still be mapped out of '0x0 - 0x1FFFFFFF' area? External flash uses the FSMC bank1 area (0x6400 0000 - 0x67FF FFFF).


    Most debuggers automatically use the BKPT instruction in read/write regions, reading out the existing instruction and inserting a BKPT; this is the same as debugging code loaded into onchip RAM.

    Third option 'alternatively, use a PC based watchpoint match to halt' : How can use the PC based watchpoints? Any reference link to understand this concept?


    Assuming the debugger has enabled the watchpoint unit and doesn't overwrite any changes you make, you should just need to set [0xE0001028] = 4, and [0xE0001024] = 1, and [0xE0001020] = PC to break on.
    There may be a better way of achieving this depending on which debugger you are using.

    hth
    s.