I have an application working with a HD40778 4x20 lcd.
Within the application I have commented (/* */) the functions to load custom characters and to build 2x2 & 4x2 fonts.
When I compile the fonts functions the program crashes in spite of the fact that I never call them; I got some warnings of the uncalled functions.
The font functions call the same basic ones (write command & write data) that worked initially; the code constants (216 bytes) to define the customs characters were declared in the working version.
Here one that loads the custom chars for the 4x2 font:
unsigned char code fc420[8] = { 143, 143, 140, 140, 140, 140, 140, 140 }; unsigned char code fc421[8] = { 159, 159, 131, 131, 131, 131, 131, 131 }; -- -- void loadFont4(void) small { lcd_dwn_custom_char(0,fc420); lcd_dwn_custom_char(1,fc421); lcd_dwn_custom_char(2,fc422); lcd_dwn_custom_char(3,fc423); lcd_dwn_custom_char(4,fc424); lcd_dwn_custom_char(5,fc425); lcd_dwn_custom_char(6,fc426); lcd_dwn_custom_char(7,fc427); }
I have tried calling the font functions one at a time, using the SPEEDOVL & NOOVERLAY but it did not help.
To use the debugger I had to disable (comment /* */) the HD40778 input ports but it works as expected.
Any hint?
Tia
Federico
Uncalled code breaks the call tree analysis of the compiler.
If you try a search on this forum, you will find many threads about it.
I almost read all of them, that is why I tried NOOVERLAY & SPEEDOVL to stop the tree analysis.
ITO, my tree is little and simple; I may be blind but looks ok.
Ok I buy your point but I do call the new functions and it crashes.
The font functions are called 40- 50 lines after the program starts and it is dead since reset. nada.
What happens if you add dummy calls to them?
Have you verified that your project specifies the correct amount of RAM, so the call tree analysis doesn't produce more data variables than what fits?
Thanks for your time.
If I call any of them it crashes.
I am selecting from the db a Ramtron VRS51L3074, 64 k flash, 256 bytes ram, 4k xdata & 8 k fram.
The linker reports 48FH code, 1AH idata & 1C data, pretty small; I am using it to debug the font functions.
Here is my call tree…
FUNCTION/MODULE BIT_GROUP DATA_GROUP IDATA_GROUP --> CALLED FUNCTION/MODULE START STOP START STOP START STOP ======================================================================= ?C_C51STARTUP ----- ----- ----- ----- ----- ----- +--> ?PR?MAIN?HITACHI +--> ?C_INITSEG MAIN/HITACHI ----- ----- ----- ----- ----- ----- +--> ?PR?INIT3074?HITACHI +--> ?PR?_LCD_WRCMD?HITACHI +--> ?PR?_LCD_GOTO?HITACHI +--> ?CO?HITACHI +--> ?PR?_LCD_STRING?HITACHI +--> ?PR?_V2KDELAY1MS?HITACHI +--> ?PR?LOADFONT4?HITACHI INIT3074/HITACHI ----- ----- ----- ----- ----- ----- +--> ?PR?LCD_INIT?HITACHI LCD_INIT/HITACHI ----- ----- ----- ----- ----- ----- +--> ?PR?_LCD_WRCMD?HITACHI +--> ?CO?HITACHI _LCD_WRCMD/HITACHI ----- ----- ----- ----- ----- ----- +--> ?PR?_V2KDELAY1MS?HITACHI _V2KDELAY1MS/HITACHI ----- ----- ----- ----- 0032H 0034H ?CO?HITACHI ----- ----- ----- ----- ----- ----- _LCD_GOTO/HITACHI ----- ----- 001BH 001BH ----- ----- +--> ?CO?HITACHI +--> ?PR?_LCD_WRCMD?HITACHI _LCD_STRING/HITACHI ----- ----- 0016H 0019H ----- ----- +--> ?PR?_LCD_WRDATA?HITACHI _LCD_WRDATA/HITACHI ----- ----- 001AH 001AH ----- ----- +--> ?PR?_LCD_GOTO?HITACHI +--> ?PR?_V2KDELAY1MS?HITACHI LOADFONT4/HITACHI ----- ----- ----- ----- ----- ----- +--> ?CO?HITACHI +--> ?PR?_LCD_DWN_CUSTOM_CHAR?HITACHI _LCD_DWN_CUSTOM_CHAR/HITACHI ----- ----- 0016H 0019H ----- ----- +--> ?PR?_LCD_WRCMD?HITACHI +--> ?PR?_LCD_WRDATA?HITACHI ?C_INITSEG ----- ----- ----- ----- ----- -----
LoadFont4 is the one that kills the app,
Thanks.
_LCD_STRING/HITACHI ----- ----- 0016H 0019H ----- ----- [...] _LCD_DWN_CUSTOM_CHAR/HITACHI ----- ----- 0016H 0019H ----- -----
You said you had used the NOOVERLAY switch. These two lines indicate otherwise.
Earlier you said you had warnings about uncalled segments. I think you need to go into more detail about those.
I've had many runs (pulling my white hair apart): - Of course, if I omit the calls I got the warnings. - I have used NOOVERLAY, SPEEDOVL and REMOVEUNUSED, none worked. - You are right; the tree posted is with just REMOVEUNUSED, I wanted to show that it looks correct.
My point here is that my application crashes as soon as the font functions are complied: - The application is dead from the reset, not even the first part of the main executes. - It does not matter if I call or not the font functions, cold dead. - It does not matter if I use NOOVERLAY, SEEPDOVL and REMOVEUNUSED. - Playing with debugger behaves as expected considering the variables values (obviously with no lcd output); they seem ok.
What do I mean with font functions? LoadFont4() loads custom characters into CGRam, One4() writes a 4x2 one using the customs characters, Two4, Tree4, and so on; plain vanilla.
Thanks for your help.
.
Using the derivate REMOVEUNUSED and compiling but not calling the font functions I could get the app running.
As soon as I call any of the font functions the program crashes not running even the part that was running before the call, I call the font functions +/- 100 lines after the program starts (initialization and some messages to the HD40778); the application crashes not showing anything in the lcd.
I added and called one font function at a time, same problem, cold dead from the start. The functions added use the same basic functions (writecmd & writedata) called in the part that is already working.
I used mVision debugger to trace it and had to comment some lines that write HD40778's ports but it seems ok.
Any idea?
Any idea? maybe after you answer the questions I posted
Erik
I'm sorry but I didn't get your questions.
By derivative you mean the 51 I am using? It is a Ramtron VRS51L3074 on a VersaKit-30xx.
which debugging? I am using the mVision debugger.
... your device or whatever a mVision debugger is (do you mean the uVision simulator).
I thought It could be a watchdog problem, but 1) does the simulator (if that is what you use) simulate the WD? 2) is the default start for your chip the watchdog enabled?
Anyhow with any kind of debugger it should be darn simple to see what goes on set a breakpoint as late in the process as you can and step through the assembler to see why and where it blows. With that knowledge, it should be a slapping the forehead issue.
I've had many runs (pulling my white hair apart):
That's bad enough already. But why unload all that confusing mess on us, unfiltered? So we can lose our hair over it, too?
- The application is dead from the reset, not even the first part of the main executes.
That's a jump to conclusions. There's quite a bit of stuff going on between the hardware reset event and entry to main(). Just because execution don't reach the latter doesn't mean the former already failed. It could be anything from something having broken the startup routines to failure to inform startup about a watchdog. You'll have to debug into startup to see what's going on.