ST I-CUBE_LRWAN 2.1.0 causing hardfault when timer is stopped.

[ulissestpBR]

After sending the first uplink using ST I-CUBE_LRWAN 2.1.0, the application stops in the hardfault handler. It's probably an issued with the circular buffer for timers.

Did anyone else had this problem?

Thank you.

[Tesla DeLorean]

Not anticipating a huge level of responses here..

You should probably dig into what's actually happening. Look at the registers and addresses involved, and if the structure has been corrupted, or the pointer is just non-sense.

It does look to be NULL checking the pointer, but if it points to random memory, or is misaligned the line 272 statement could potentially fault as it fetches.

[ulissestpBR]

Thank you. Actually, you were the only person I thought I'd get a reply from in this forum.

I'm debugging and trying to understand the error, but it seems that the pointer actually advances to a not allowed memory region, which causes the hardfault.

BTW, I really think you should get hired by ST. You often know much more of their devices than they themselves do, and help so many more people than they do too. I'm serious.

Thanks again.

[Tesla DeLorean]

Well does look to be chasing a linked list.

So either some portion has become corrupted, or there's expectations the allocated memory is clear, ie calloc() vs malloc()

For GNU/GCC based tools watch how the heap is allocated, and the potential for the stack/heap to collide with very large auto/local allocations within subroutines or related call-trees.

They probably should pay me, but they don't...

[ulissestpBR]

Actually I'm having such an inconsistency now. Sometimes the hardfault is caused and now a lot of times it is not.

It seems IAR compiler is trolling me. I'll try to build the project in a different version to see if the problem persists.

And they definitely should pay you. Did you ever try to apply to a position in ST? I think you should consider that!

Thanks a lot again.

[ulissestpBR]

UPDATE: I have found the problem.

After sending an uplink, the static void LoRaMacHandleMcpsRequest( void ) function in LoRaMac.c file access the timer table - by the scheduler implemented by ST in this version - to stop a timer that was not even started. This causes the hardfault.

And now a workaround will have to be implemented to solve this problem.

I just can't get it. They had a good and working stack (version 1.3.1) which had been extensively used and debugged by the community. But you know what? Let's shake things up a bit around here. Let's throw that away and start from scratch with a more complex, completely rewritten stack. Big chance of success!

[PMX]

I run into the same problem while porting LoRaMAC V4.7.0 to STM32L072CZ (Murata ABZ).

Increasing the Minimum Stack Size to 0x600 solved the problem for me.