I've built a test app that uses rtx with a graphics library to drive the a70 lcd with a mini2440. The app works as expected when I load it to ram over jtag and let it run. But if I use uboot to load it over usb to 0x30000000 and try to start it with 'go' I get nothing. Any thoughts?
I have seen a variety of start address, ie 0x31000000 and 0x32000000 I use to use 0x31000000 with Forrest Bao's Deploying u-boot, Linux kernel and GPE onto Mini2440, powered by SAMSUNG S3C2440
I think it's back to ghosts in the hardware. my usual troubleshooting method is when encountering a failure that is unexplainable, I go back to the last known good and work forward. so when my LCD driver app wouldn't work when starting it from memory via u-boot, I went back to my test LED app that always works. guess what... it didn't work. after hours of rebuilding for various areas of ram, I gave up frustrated. Came back this evening and voila! First time powered up the LED app ran. What?!?! nothing changed since night before. reset the board (via power source) ran it again. Nothing. Huh? it just worked and now it won't? Tried resetting with the reset button, resetting via power source and resetting via u-boot. sometimes the LED app works and sometimes it doesn't. I can't find a common thread amongst times it works. Thinking this must be a hardware issue... maybe a cold joint issue? Thoughts anyone? Little hair left in Iowa. <sigh>
What is displayed on a terminal? Have you considered using strace to invoke your application. Just maybe a memory issue. Have you compiled with stack checking? Regards, little and grey hair.
So I'm back at it and experiencing more oddities. I've put debug messages in the entry and exit of my main functions, over serial to see where it is dying. (Recall it all works fine, executing from SDRAM over JTAG.) Now I am saving image NAND. Then upon reset, using u-boot to copy from NAND to SDRAM and execute from RAM. Program starts fine, but one time it might run through the first 20 functions before dying. After a reset it might run further into the program (or less). It tends to do better if I have the USB cable pulled out. This has to be a power problem right? I'm using a 3.0A power supply and the voltages look good... Time for a new board?
Try run some other program. If it runs without hassle your problem is software and not hardware!
Does uboot enable the interrupts? Is your stackpointer setup correctly? Is your cache memory setup correctly? Does your application expects the correct memory size? Do you write to memory in your own application? Do you overwrite memory regions with TLBs (when cache is active) or uboot code (maybe still required to handle interrupts)? Power fail: Is your uboot running stable on your board? Can it start Linux and it just works? If yes: your board is working and your power source as well. Using USB means there is some DMA running on your system (reading and(!) writing). Maybe you confuse the USB DMA engine if you write to its memory by accident. Take a careful look to the memory layout uboot uses. And locate your application and its data in the remaining *free* area.
These may help: 1) cat /proc/meminfo 2) man free => for information ( free -l )
Thanks Juergen for the ideas. I worked with vxWorks on PPC long ago, so embedded concepts are familiar, but am new to ARM and to working at the hardware layer. My app is a no-os, application, using KEIL to develop in 'C' and compile. In the init, prior to 'Main' I disable the MMU, ICache and DCache. App is compiled to execute from the start of external SDRAM 0x30000000. Code segment is at 0x30000000, size 0x1000000, data is at 0x31000000, size 0x1000000. (These were the suggestions with the 2440 BSP) So, let me show my ignorance here. I assume that u-boot is a 2-stage loader, booting from first 4K of NAND to IRAM, and then copying itself into SDRAM... anyone know if this is right? how would I go about understanding where in SDRAM it is located maker sure I am avoiding conflict. I guess I was expecting a bit simpler development environment... meaning, 3 basic development stages: 1) develop in simulator, 2) download and debug using JTAG 3) use vivi or u-boot to download (or burn and copy) image and then transfer control using 'GO 0xXXXXXXX' Also, when things go wrong, I expected them to be wrong consistently (would die in the same place every time). Being random, where it dies, put me on the 'power problem trail'. Perhaps there are other reasons for random lockups.(yet to be found) I'm actually at the moment working on writing my own mini-bootloader, that will just copy my app from nand to SDRAM and then transfer control. At least this way I will know for sure what is happening behind the scenes. (Sure wish source was available for SuperVivi) but I am learning plenty from analyzing U-boot and nboot code. To answer everyone else's assumptions, I am not using Linux. (Although I will load it later on, to see that the platform is stable with something other than 2440test.) P.S. Is anyone else tired of translating Chinese web pages looking for tidbits of information? Hats off to those guys. They seem to know what they are doing. this late night stuff is beginning to affect my day job, and my wife is now referring to my mini2440 as my digital mistress. Thanks to all who have replied.
Oh my. Problem solved... (I think). I realized after as I was re-reading my last post, that I may have forgotten a step. Checked out my code and realized I was not invalidating the dcache before the branch to Main. Added that and voila. There she goes. Why it was manifested in seemingly random areas of code it would reach... I do not know, yet. ...going to bed now. it has been a long several months to get to this. Now I have the test demo going, I need to finish my own bootloader (just to say I can) and then on the real application. YEAH!
Cache handling is always a source of pain... :) Invalidating the cache lines was my first thought when I read your lines about disabling the MMU. But you where faster... Happy hacking