I have a working software that I need to upgrade (Flash size is 44638 bytes), but sometimes when I declare basic variable, my software is having weird behaviour. This is not the first time that we saw that, but we always find a workaround like declaring it as an external in other file.
Right now, when I add :
uInt8 UartReadyToSend;
In my modbus.c file, my software is not correctly responding and seems to block the software. This variable is commented in all my code. I can see that this is not working normally when this variable is declared because :
1) My software is simply not responding.
2) I have a uart terminal that returns me some variable of one of my function and it's stuck on the same state.
It's probably a configuration issue, but I don't know what can cause this. My code optimization level is set to 8 in the option of my target.
Here is some info :
Our debug adapter : https://fr.farnell.com/en-FR/silicon-labs/debugadptr1-usb/adaptor-usb-debug-for-c8051fxxx/dp/1186943
IDE-Version: µVision V5.25.2.0 Copyright (C) 2018 ARM Ltd and ARM Germany GmbH. All rights reserved.
Tool Version Numbers: Toolchain: PK51 Prof. Developers Kit Version: 9.59.0.0
Toolchain Path: C:\Keil_v5\C51\BIN
C Compiler: C51.exe V9.59.0.0
Assembler: A51.exe V8.2.7.0
Linker/Locator: BL51.exe V6.22.2.0
Librarian: LIB51.exe V4.30.1.0
Hex Converter: OH51.exe V2.7.0.0
CPU DLL: S8051.DLL V3.122.0.0
Dialog DLL: DCYG.DLL V2.75.0.0
Target DLL: SiC8051F.dll V4.4.0.0
Dialog DLL: TCYG.DLL V2.72.0.0
Thank you.
volatile?
No this variable is declared as :
In my .c file.
Don't know if you were asking me to add it, so tried adding volatile to it --> behaviour didn't change.
Post your .m51 file. It could be that your ram variable is running into the stack space. Can you declare it as xdata (if you have any)? We would need a clearer picture of your device RAM memory and how you are using it.
Still gives the weird behaviour when declared as :
uInt8 xdata UartReadyToSend;
Declaring it as *uInt8* or *uInt8 xdata* doesn't seem to change the .m51 file (at least the line when this var is).
Here is my .m51 file :
m51.txt
Looking just at a single line of map file rarely sufices to pin down a problem. You'll have to search the entire file for any difference whatsoever. Compare the map file from a good build with a broken one. Compare hex files, if necessary, to find out what actually changed.
While at it, you might want to take care of those warnings about unused code (and read up on why that's actually a non-negligible problem on 8051 code).
As GrantB and the support suggested, it was an issue with my stack, probably by using function pointers while I had warning about unused functions.
From what I know, this was because my call-tree was wrong so I could fix it by cleaning unused functions warnings or :
--> Disabling the memory overlaying by specifying the linker directive NOOVERLAY in the µVision dialog 'Options for Target - BL51 Misc - Misc Controls'.
NOOVERLAY option worked for me.