K70 Jumps to Unknown Memory Areas

[darsnack]

Hi

I am currently trying to program a K70F120M. Unfortunately, the program never seems to get to main() when I flash it. If I run it under the debugger and ask the debugger to stop at the program start point, it will pause execution at the start boot script. As I step through, the program will all of a sudden jump to an instruction at an unknown location in memory like 0xFFFFFFFE. I do not know why this is happening. My only guess is that when I flash the chip, I need to include an offset so I don't right over the security area. I am wondering if there is some absolute jump that is being screwed up by this offset. Has anyone run into such an issue? Or perhaps, you have had the security area issue, and if so, how did you overcome that?

[mjbcswitzerland]

Kyle

It is not possible to step the code due to the watchdog. The watchdog gives you a few clock cycles to either set it up or disable it and when stepping code from the entry these clock cycles are used up before the watchdog setting is made - when this code is executed it then is considered an invalid access, triggers the watchdog and throws the debugger to a strange address.

There are more details in the Watchdog section of this document: http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis_demo.pdf

What you need to do is set a break point "after" the code that configures/disables the watchdog and let it run to it (past the watchdog setting) and then stepping and debugging from there works normally. Thsi is required for all K parts - KL parts use a different watchdog (COP) and don't have this 'difficulty'.

Regards

Mark

http://www.utasker.com/kinetis.html

[darsnack]

Hi Mark

I attempted your suggestions. The very first line in main() disables the watchdog. I have my first breakpoint set after that line is done. When I run the debugger, the code still jumps to a weird memory location (same as before). I suspect that in the initialization code, before my code, the program counter is getting set to some unknown location, causing the program to crash. Perhaps this is a watchdog issue, but I cannot edit code that is not mine. I believe the issue is unrelated to the watchdog. Thank you for your suggestions though, I am sure they will help after I get past this hurdle.

Thanks

darsnack

[mjbcswitzerland]

Hi

What is programmed at addresses 0x00000000 and 0x00000004 ?

These must be the initial stack pointer value and the initial program code location - if these are left at 0xffffffff the processor can't start.

Code should not be loaded with an offset (unless there is a boot loader coordinating it). The flash configuration area should be set up as requred by the code and written as part of the operation.

Regards

Mark

[darsnack]

At 0x00000000, I have .long 0xffffffff. Same for the rest of memory up to 0x00000004. I suspect that the offset is causing an issue. Unfortunately, every time I try to flash without an offset, I get an error saying I am writing over a secure memory area which is not allowed. I have already performed a mass erase on the device, and confirmed the memory is in fact UN-secure. So, I have no idea why I still get this error.

[mjbcswitzerland]

Hi

Most tools give a warning about the value written to the security area but it shouldn't necessarily be an error.

Check your binary file (in a binary editor) that you are loading to see what it has at the addresses 0x400..0x4f

Typically it has

ff ff ff ff ff ff ff ff ff ff ff ff fe ff ff ff

where the 0xfe is the "unsecure bit".

If is is all 0xff simply modify the single byte to correct it.

If it is random looking data it is probable that the flash security settings are not being inserted correctly and it is random code, which is dangerous since it could write a pattern that makes the chip unusable because it cannot be programmed anymore. In this case you need to get the problem correct at the source.

It may turn out that the programmers are setting a pattern to intentionally set some level of security, in which case you need to find out why the programmer is not allowing it to be programmed (probably a setting in the tool somewhere which is trying to avoid 'presumbly' bad code from causing  problems).

Regards

Mark