g_pfnVectors() at 0x0 issue on FRDM-KL27Z

[littlemonster]

Hi,

First of all, I know that this question has already been asked some times but my issue is not exactly the same as the former questions.

I am working with the FRDM-KL27Z board. For some reason, at a precise state, in debug mode, my program falls down in the HardFault handler function because It reaches the g_pfnVectors() at 0x0. I am not doing something too much sophisticated or complicated and the part of the code which is failing  works well on computers or smartphones. Weirder, when I override the default HardFault handler which is defined as weak by default, my handler is not reached and the g_pfnVectors, instead of redirected the code to the hardfault handler, jumps directly on the ResetISR handler.

It's a professional work so I won't be able to show you some code.

I read that it could be the synchronisation between the PC and the debugger (here) which could be the reason of that bug however when i remove the failing part, there is absolutely no issues.

To help, I precise I am working with MCUXpresso IDE with the newlib nano library.

Thanks for your help !

Damien

[littlemonster · Accepted solution]

mjbcswitzerland‌

BlackNight‌

Hi all,

I finally was able to solve my issue !

In the code that was failing, I had a structure like that :

struct a_struct

{

      int32_t tab[512];

      int32_t tab_length;

};

The problem was that structure was statically allocated and used by reference a lot of times so at some point the stack was erased and corrupted by the "tab" value which was mostly filed by zeroes (the reason of the jump to the 0x0 address I think). By allocating dynamically this tab and reducing the tab type to uint8_t, the issue was solved !

Thanks to you two for having trying to help me =)

Regards,

Damien

[mjbcswitzerland]

Hi Damien

I didn't understand  exactly but it sounds that it was a lack of memory (stack corruption)?

Regards

Mark

[mjbcswitzerland]

Hi Damien

It sounds like code is jumping to the address 0, which then causes a hard fault(?)

If I remember correctly, there are some threads reporting that using semi-hosting can cause some strange effects/unexplained errors when working in debug mode. If you don't think it s a coding error as root cause try ensuring no semi-hosting is enabled.

Regards

Mark

http://www.utasker.com/kinetis/FRDM-KL27Z.html
http://www.utasker.com/kinetis/Capuccino-KL27.html

[littlemonster]

Hi Mark,

Thank you for you answer. Indeed, the code jump at the address 0 and cause a hard fault.

I tried to disable semihosting as you advised it but unfortunately it doesn't change anything.

This is the debugger window, you can see that I have no history of what happened before jumping to the address 0.

Regards,

Damien

[mjbcswitzerland]

Damien

I don't know which way the call stack is showing (either attempt to run code at 0 causing a hard fault - or a hard-fault causing a jump to 0)?
In any case there is no pre-history to help out.

I would try putting a HW breakpoint on the address 0 to see whether that is hit. With a paue there and without the exception taking place it may help the call-stack viewer to give more info.
Also do a dump of the stack at that time  to see whether you can see traces of previous calls.

Do you have the same issue in release mode?
What is the RAM utilisation like? (how much stack margin?)

If you post the binary to be loaded on to a FRDM-KL27Z can the same issue be seen just by letting it run?

Regards

Mark

[littlemonster]

The stack starts down and ups.

I tried to put a HW breakpoint at address 0 but It is never reached. So I can't get a bigger stack trace than before.

Unfortunately the issue is still there in release mode.

I configure the memory the following way knowing that I have 0x4000 bytes of RAM available:

   - 0x2000 bytes for the heap

   - 0x1000 bytes for the stack

   - The rest of the memory is used by the data

So when I compile, I've got that : 

Memory region            Used Size        Region Size        %age Used

PROGRAM_FLASH:       61480 B                 64 KB              93.81%

                     SRAM:       16020 B                 16 KB              97.78%

              USB_RAM:             0 GB                 512 B                0.00%

Here are screenshot from my configuration :

Finally, I've worked on a FRDM-K22F board before and managed to load the binary into the board but with that one I can't load it.

Regards,

Damien

[mjbcswitzerland]

Damien

If you post the (release) binary I can see whether I can load it to my FRDM-KL27Z board.

If it hard faults I may be able to see something (does it immediately fail or does it take some time?)

Regards

Mark

[littlemonster]

I am sorry but for some confidentiality reasons I can't send you the binary.

And the code fails immediately.

Regards,

Damien

[BlackNight]

Hi Damien,

not sure what you mean with 'fails immeditely', but I think you see the hard fault before your code reaches main.

I'm not sure what IDE/debug connection you are using, but I would disable the 'run to main' function and instead step through the startup code to narrow down where it causes the fault.

I would not trust too much on the stack backtrace, because depending of the source of your hardfault, this might be a red hering.

It might be worthwile that you implement a custom hard fault handler (see Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse ) which helped me many times. Not sure why the 'weak' did not work for you: in any case, you might uncomment/remove that dummy weak handler and use your own one.

As for the hard fault itself: common causes are:

- misaligned memory access (e.g. accessing an odd address with a 32bit access)

- using a peripheral which is not clocked (common case is accessing the RTC which is not clocked and/or not powered by VBAT)

- trying to write to read-only memory

I hope this helps,

Erich

[littlemonster]

Hi Erich,

Thank you for your answer. When I say that the hard fault is reached immediately I answer to Mark when He asks if there is a delay before reaching the hard fault or if it's immediately.

As I precise it in my first message, I am using the MCUXpresso IDE with the GDB PEMicro interface.

Thank for your link about the hard faults, it seems pretty interesting and I will have a look !

As I said, the code is working on a lot of other platforms like computers, smartphones, STM32 F4 and F7 and even on a FRDM K22F. So i'm sure it is not a peripheral issue. However I am not certain about the misaligned address or the write to a read-only memory. I'll investigate.

Regards,

Damien

--> EDIT : I tried to use the custom hardfault handler as your link explains. However I have the exact same behaviour than when I tried to implement the handler with only a printf inside : The "g_pfnVectors() at 0x0" step is not reached nor the hardfault handler and the program jumps directly on the ResetISR function.

[mjbcswitzerland]

Damien

If your binary is confidential, try changing it a bit  (removing parts of interest that could be stolen) and if it still crashes you could post it.

Regards

Mark

[littlemonster]

Mark

I appreciate your interest for my issue however it is the confidential part which is failing. So this option is definitely not possible.

Regards,

Damien

[mjbcswitzerland]

Damien

I don't think that I can help any more at the moment in this case.

If you do not make progress and the project delay or investment in time does become an issue I do offer a professional service specialising in quickly identifying and solving such problems (usually a binary if adequate and a map file can also aid a little). This would allow you to set up an NDA - you can find details and contact address at http://www.utasker.com/support.html

Regards

Mark