We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello everyone,
The program with several source files and it compiles fine and there is no problems writing to flash memory.
Initially, the main() program only writes some characters to the LCD. If I run it, all is well.
Problems arise when I add a function (very long one) after the LCD.
int main (void) { /* LCD Setup */ GPIO8->DDR = 0xFF; /* P8.0..7 Outputs (LCD Data) */ GPIO9->DDR = 0x07; /* P9.0..2 Outputs (LCD Control) */ lcd_init(); lcd_clear(); lcd_print ("Test"); init_EPL(); }
When the application starts on the eval-board the LCD is frozen (nothing is written to the LCD). Its as if the code didnt even make it to the lines where the microcontroller writes to the LCD. But when I remove the function again the application runs fine.
I realize this is a long shot, and that this might be way too little information for you to be able to help me, but I have no idea on how to fix this problem and I am just looking for some suggestions or any ideas.
Thank you and regards, Leon
Hey, thank you for trying to help and the effort!!
Does lcd_print() busy-loop until all characters has been written, or do you make use of any interrupt function to actually send the characters to the LCD? I am using the same functions as the blinky example. I am pretty sure it does.
Have you tested to toggle an IO pin within main() and check with an oscilloscope how many toggles you get? Don't have oscilloscope handy at the moment :(
Is it possible that your code do write to the LCD, but the program then crashes and manages to reset the LCD? This doesn't seem to be the problem. I added a delay after the LCD prints (like you suggested). Still a blank screen. Its as if the code never runs.
What happens if you add a delay between individual lines in main() - or at least a busy-loop delay after lcd_print() - preferably by initializing a timer and wait a specific number of timer ticks? Same thing.
Is it a C program or a C++ program? C - Keil uVision with Realview compiler
Do you declare any more local variables after the lcd_print() function, so you may run out of stack space? There is 2 more functions.
Forgot one thing - does the startup file initialize any watchdog timer that you may fail to feed/kick? I have no idea! Not sure what this is.
If you don't have an oscilloscope - do you have a LED and a suitable resistor, so you can light the led when you enter main() and then after a couple of source lines add a delay loop (so you have time to see the LED) before turning it off?
Do you have a JTAG debuger (such as ULINK) that allows you to put in a breakpoint?
What happens if you single-step your application in the simulator? Will you reach main()?
I do have LED's. And I do I have ULINK.
Simulator or debugger? (PS, what is the difference exactly?)
I am pretty certain the simulator does not enter the main function.
Assemble code, it gets stuck here.
0x00000120 E5902008 LDR R2,[R0,#0x0008] 601: ANDS R2, R2, #SYSSTAT_LOCK 0x00000124 E2122001 ANDS R2,R2,#0x00000001 602: BEQ PLL_Loop 603: ENDIF 604: 0x00000128 0AFFFFFC BEQ 0x00000120
source in str91x.s
PLL_Loop LDR R2, [R0, #SCU_SYSSTAT_OFS] ANDS R2, R2, #SYSSTAT_LOCK BEQ PLL_Loop
"Simulator or debugger? (PS, what is the difference exactly?)"
Different things. The debugger can be used with a simulated ARM. And with the ULINK, the debugger can also be used with your real hardware.
Since you have a ULINK, you can test both ways. If you set a breakpoint at the start of main() - will you reach this breakpoint when using the simulator? Will you reach this breakpoint when running on the live hardware?
Since you get stuck in the startup code, it would be best if someone who have been using a similar processor to yours could help out a bit. I have only worked with the NXP chips, and they have different startup files since they have different peripherial devices around the ARM core.
If the PLL fails to lock on on the real hardware, you may have specified a too high or low PLL multiplier, resulting in a PLL frequency outside the allowed limits. It can also be the result of the clock crystal (or if it is an RC oscillator) for some reason not producing any oscillation at all, or running very unstable.