Hi,
I am new to Keil and I am implementing some crypto algorithms on a platform using ARM cortex M23. The platform has 3KB RAM and 30KB ROM.
When I debug, if the plain text size is small (2048bytes), everything is fine. But if I increase the size of plain text to 3072 or 4096, the encryption will be skipped and I cannot see the result.
I added breakpoint right before and after the encryption function call but it doesn't stop. It goes back to the beginning of the whole program directly after I click "step over" before function call.
It seems like the text is too large to be encrypted correctly, maybe there is an overflow? But the builder did not report any error, the RO/RW size does not exceed 30KB/3KB either.
I saw many people suggest to lower the optimization level of Keil, but I am always at -O0, why this still happens?
Thanks in advance.
Hiilda said:I am new to Keil and I am implementing some crypto algorithms on a platform using ARM cortex M23. The platform has 3KB RAM and 30KB ROM.
3 KB RAM is very less. You need to be careful when you define the stack and maybe heap.
Hiilda said:When I debug, if the plain text size is small (2048bytes), everything is fine. But if I increase the size of plain text to 3072 or 4096, the encryption will be skipped and I cannot see the result.
Do you keep the strings that should be encrypted in RAM? Did you check your map file if your application does not allocate more than 3 KB? I could imagine that the original string, as well as the encrypted string, needs to be stored in RAM. If this is the case, 3 KB RAM would be way too less.
Hiilda said:I added breakpoint right before and after the encryption function call but it doesn't stop. It goes back to the beginning of the whole program directly after I click "step over" before function call.
This looks like a reset or exception which is caused by your encryption algorithm. You should see the reason when you single step through your encryption algorithm and if you watch the Exceptions dialog. I'm sure that no code is skipped or not translated.
Thanks for the reply! I am using a open source library, so I don't know much details about how the author allocates stack and heap.. but I will manage that. By the way, how can I know whether there is stack overflow?
I didn't keep the string in RAM, I kept it in ROM. And the encrypted string is 128bits, so I don't think it will run out RAM space. Anyway, I will go through the code step by step and see what's going on. Where can I see the Exceptions dialog?
This is from the map file:
==============================================================================
Total RO Size (Code + RO Data) 4560 ( 4.45kB)
Total RW Size (RW Data + ZI Data) 1032 ( 1.01kB)
Total ROM Size (Code + RO Data + RW Data) 4560 ( 4.45kB)
It looks OK.
Hiilda said:I am using a open source library, so I don't know much details about how the author allocates stack and heap.. but I will manage that.
The stack and heap is usually not defined in the library. You define both in the startup files or in your linker scatter file.
Hiilda said:By the way, how can I know whether there is stack overflow?
There is no stack overflow exception unless you don't use the MPU for the stack. A stack overflow will overwrite other variables or the application will crash when returning from a subroutine. In the map file, you see where the stack is located. This application note 316 tells you how to analyze the stack consumption:
https://developer.arm.com/documentation/kan316/latest/
Even if you don't use a Real-Time OS, you should read the paragraph "Main stack watermarking". Then you could see the current stack consumption in the uVision debugger.
Hiilda said:I didn't keep the string in RAM, I kept it in ROM. And the encrypted string is 128bits, so I don't think it will run out RAM space.
OK, this looks reasonable.
Hiilda said:Where can I see the Exceptions dialog?
Menu 'Peripherals - Core Peripherals - Fault Reports'.
Hiilda said:Total RW Size (RW Data + ZI Data) 1032 ( 1.01kB)
This looks extremely low but might be correct.
Thanks for the reply!
I found out where is the problem:
There is hardware watchdog, which will reset the system in 180 ms if it is not served. When I encrypt larger text, it will take more time to process. If the execution time exceeds 180 ms, the system will be reset and I will see it goes back to the beginning of my program. If I disable it, everything is fine.
I will accept your reply and close this topic. Yet, our discussion about stack analysis is very helpful to me because I need to measure the memory usage, and stack consumption would be a good choice.
Thanks again for the discussion!