uv4.21 - breakpoint problems

Ok I guess.
Anyway, I'll disregard your apparent tone and politely let you know that the two changes did not occur at the same time.

Still under version 4.20 we moved to the NOR and we tested fairly extensively all the functionality we have developed running from the NOR but we never used any break points in this time.

I upgraded to 4.21 and again it ran fine. I began continuing development and my breakpoints weren't working.
(And I didn't blame the tool I was just stating what I had done to encounter my problem)

So back to the question. I disagree breakpoints shouldn't really be a very invasive addition, particularly with Cortex-M devices. Also from what I thought of Cortex-M3 devices I can't recall any reason why a breakpoint couldn't be at any location in the memory range (after all it does execute from this range).

Do you know that this is the case? Do you know of any links that might shed some light on this?

Thank you for your time.

Regards,

Marc

Ok I guess.
Anyway, I'll disregard your apparent tone and politely let you know that the two changes did not occur at the same time.

Still under version 4.20 we moved to the NOR and we tested fairly extensively all the functionality we have developed running from the NOR but we never used any break points in this time.

I upgraded to 4.21 and again it ran fine. I began continuing development and my breakpoints weren't working.
(And I didn't blame the tool I was just stating what I had done to encounter my problem)

So back to the question. I disagree breakpoints shouldn't really be a very invasive addition, particularly with Cortex-M devices. Also from what I thought of Cortex-M3 devices I can't recall any reason why a breakpoint couldn't be at any location in the memory range (after all it does execute from this range).

Do you know that this is the case? Do you know of any links that might shed some light on this?

Thank you for your time.

Regards,

Marc

Which device are you using for your product?

Let's assume it is something like this device:

http://www.keil.com/dd/chip/5722.htm

The LPC1810 accesses external NOR flash via the External Memory Controller (EMC). I assume upon reset your device's EMC is at its default values and not set to talk to NOR flash.

I assume that when the debugger tries to load the breakpoint register with the NOR flash address, it cannot yet access NOR flash, and yields an error.

you could write a debug command

BS 0xAAAA

, where 0xAAAA is the memory location where you NOR flash resides. That way after your EMC is configured by your project, you could quickly set a breakpoint.

Hi Ron,

Thanks for your reply and suggestion.

I'm using an LPC1788 so yes it access the NOR via the EMC.

I initialize the EMC at startup before the call to main as follows:

Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  SystemInit
                IMPORT  emc_setup_asm
                IMPORT  __main
                LDR     R0, =SystemInit
                BLX     R0
                LDR     R0, =emc_setup_asm
                BLX     R0
                LDR     R0, =__main
                BX      R0
                ENDP

I also (redundantly) configure the EMC via a debug/flash program INI file. In any case even if I wait until after the EMC is properly configured I still can not add a breakpoint.
(Note I can see the disassembly of the NOR)

I tried the 'BS 0x800000' command as you suggested but I get the same error messages.

Have you ever encountered this? Am I correct in thinking that I should be able to add breakpoints to the code in external NOR?

Thanks.

M