Hardware Breakpoints in external FLASH

charlesherrera · ‎2009-01-14

Posted on January 15, 2009 at 00:00

joseph239955 · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hi Charles,

I don't know. I emailed a friend in KEIL and will forward the answer if I got a reply. (There will be some delay due to holiday.)

regards,

Joseph

charlesherrera · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hello joseph, STOne, jj, jilisegiar, and all,

Below is a summary of what I have learned about STM32 Hardware Breakpoints and the ability to use debuggers on code in external flash. Thank you all for your help and suggestions.

Hardware breakpoints can only be used on internal memory on the STM32. A hardware breakpoint will not work on any external Memory. This is not a bug in the STM32 and the Tool Chains are not failing, it is simply that hardware breakpoints are not supported for external memory by the STM32. The hardware breakpoint unit can only set breakpoints in the address range of 0 to 0x1FFFFFFF.

For addresses 0x20000000 and higher the ''Watchpoint on PC match'' feature in the DWT could be used instead. Unfortunately I have been unable to find any evidence that any of the debuggers available support this feature. In the cortex documentation it is mentioned that PC match is not recommended for watchpoints because it stops after the instruction. Even with this drawback this type of ''breakpoint'' would be very helpful and though not as good as a hardware breakpoint it would be much better than nothing.

Since I will have code running from external flash which will be larger than the internal Flash space I will be forced to do extra work just to debug the unit. I will have to either come up with special hardware with external ram to use software breakpoints for debugging, or go through a process of moving the code that needs debugging into internal flash as needed to debug. Any of these options requires extra work and changes to the system from its normal state.

Regards,

Charles Herrera

joseph239955 · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hi Charles,

I haven't heard from my friend about the debugger support on this yet.

Meanwhile, in case you have access to KEIL uVision, you could try using breakpoint intrinsic in your C code

void __breakpoint(int val)

e.g.

__breakpoint(N); // N is a value from 0 to 255

(Details are in

http://www.keil.com/support/man/docs/armccref/armccref_cjahbcfh.htm )

I don't know if IAR got the same feature. If not, you could use inline

assembler to insert a breakpoint in your code :

(I hope I've got the syntax right)

asm('' bkpt 0'');

Joseph

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hi Charles,

Thanks for the update summary :) and the the reply.

I can suggest you that debug your Code with our 512K Flash devices ''E'' and split it in two modular parts or more... {if you would like to easily debug it with HW breakpoints} By the way, how much code memory your application is using ?

Cheers,

STOne-32.

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:57

@Charles-

Like STOne-32 - my group enjoyed/benefitted from your detailed post - thank you.

Believe that STOne-32 and I have hit on similar idea (he says split into 2 or more ''modular parts'') and my idea was to design/build a ''special b

joseph239955 · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hi Charles,

I got reply from my friend in KEIL and confirm that at the moment the uVision debugger cannot handle hardware breakpoint outside of CODE region.

So the only solution right now is to insert breakpoint in software directly.

regards,

Joseph

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hi Charles-

The chip we used in the past was 74HC/HCT688 - it is an 8 bit ''identity/equality'' digital comparator. Connected in cascade these allow you to generate a ''trigger'' signal when a ''match'' is detected. We used a simple, 8bit uC to generate our breakpoint ''target'' bus value - when the dut uC matched that address we triggered. We used a simple,16 key hex keypad to set our trigger address. We went so far as to program the simple micro with over 10 key addresses - so that setting and changing the trigger address became faster/easier.

The simplest multi-processor scheme we hit upon was dedicating one uC to the ''main'' code - and storing the various functions/subs in separate uCs. Main was responsible for enabling/CS the selected micro just prior to transferring control. We modeled this technique from ''bank switching'' different eproms - to avoid/exceed the past 64KB address limits. I recall that we had some (several KB) of repeated or overlap code in the base of each eprom - to allow safe and graceful transition from memory to memory.

We will be working on such a technique using multiple STM32's - in our case seeking to boost performance via simple ''parallel processing'' - however the total code size does expand - and may provide the solution you seek. Hope this sparks some ideas...

charlesherrera · ‎2011-05-17

Posted on May 17, 2011 at 12:57

Hello,

Thanks for all of the suggestions. I have used strategically placed software breakpoints compiled into the code asm('' bkpt 0'') and they do work. Also we are using the 512K E devices for development. I don't know the size of the codespace yet. It is projected to be larger than the available codespace in the internal flash. There is also lots of data space needed, some of which needs to be in internal flash, forcing the use of external flash for code. The multiprocessor approach sounded interesting as well as the bus matching chips.

Regards,

Charles Herrera