2018-09-11 07:25 AM
My problem:
I bought the new demo board but it doesn’t work with sigfox credentials.
STM32CubeExpansion_SFOX_V1.1.0\Projects\B-L072Z-LRWAN1
I am using IAR system environment.
I see the same problem using both ATcommands and pushButton examples.
// original default data sigfox_data.h
sfx_u8 encrypted_sigfox_data[] ={
0x98, 0xBA, 0xDC, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF, 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, };
I made the jumper settings (JP9, SB13,SB26) and the personalization and activation sequences on murata website as per document UM2245.
When into the file "sigfox_data.h" there are the original contents (above) the examples works fine.
Once I put the new credentials instead of the original ones I see different ID and PAC with AT commands (PAC is zero originally and now is not zero).
After that, when trying (AT$SF command) to send an RF message, calling the function "SIGFOX_API_send_frame()" such function locks without come back at return point.
What may be the source of such a problem?
Thank you in advance for any help.
Luca Pizzini
2018-11-26 05:35 AM
After a lot of time with help from ST, the problem has been solved. It was a stack problem. Doubling the stack space, the problem disappear. This problem only occurs with the IAR toolchain. At the moment nobody has explained to me why the other toolchains work fine without enlarging the stack.
2018-11-26 06:20 AM
GNU/GCC typically assigns all available RAM from top down for stack. Other tools may silently collide with heap, or use less resources.
Understand the depth you're actually using, and set it appropriately. Pretty sure ST does very minimal testing.
2018-11-26 06:32 AM
Clive,
thank you very much for your explanation.
The answer is clear and simple, now I have understood what I had to know.
Thanks again
Luca