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
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?
Thanks for your time.
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.