• Locked Locked
  • Replies 5 replies
  • Subscribers 119 subscribers
  • Views 5752 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
Parents
  • 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.
Reply
  • 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.
Children
No data