NDK/NSP problems with OMAP-L138

I've just tested the "ndk_evm6748_bios6_helloWorld" example and it works:

[C674X_0] Using default MAC address 

[C674X_0] Using MAC Address: 00-08-ee-03-14-99 

[C674X_0] MAC Address = 00-08-ee-03-14-99 

[C674X_0] EMAC should be up and running 

[C674X_0] EMAC has been started successfully 

[C674X_0] Registeration of the EMAC Successful 

[C674X_0] Service Status: DHCPC    : Enabled  :          : 000 

[C674X_0] Service Status: DHCPC    : Enabled  : Running  : 000 

[C674X_0] Link Status: 100Mb/s Full Duplex on PHY 0 

[C674X_0] Network Added: If-1:192.168.0.62 

[C674X_0] Service Status: DHCPC    : Enabled  : Running  : 017 

I had to change the GEL file though, because it was not even booting (I was using the OMAP_DSP file, and changed it to the C6748 one). That puzzles me. Why the OMAP DSP gel file doesn't boot???

Anyway, that confirms I don't have an hardware problem. So now, why my ARM example doesn't work????

I went back on trying the ARM examples, without changing a single thing, now I get there:

[ARM9_0] Using default MAC address 

[ARM9_0] Using MAC Address: 00-08-ee-03-14-99 

[ARM9_0] MAC Address = 00-08-ee-03-14-99 

[ARM9_0] EMAC should be up and running 

[ARM9_0] EMAC has been started successfully 

[ARM9_0] Registeration of the EMAC Successful 

[ARM9_0] Service Status: DHCPC    : Enabled  :          : 000 

[ARM9_0] Service Status: DHCPC    : Enabled  : Running  : 000 

It still hangs. What is going on, I haven't changed a single thing! 

EDIT: I powered off the board and tried again and back to square one, it hangs at [ARM9_0] Registeration of the EMAC Successful 

I did some test again, still no luck. The ARM side is always stalling after the EMAC init, like mentioned in original post of this thread. Some notes I wanted to add:

- I'm using TI OMAP GEL files provided by Alan DeMars, for both the DSP and the ARM;

- The printf() shown in the Console appears MUCH faster when I load the DSP application than when I load the ARM. It really feels like the ARM is a turtle compared to the DSP being a rabbit when printing (and probably executing) the EMAC initialization. Is that a bad sign or is it normal?

anybody has an idea of what I could try? Am I the only one having problems running the examples on the ARM? Until I resolve this, I can't really design the application on the ARM...

DT

DT,

I have moved this thread over to the OMAP-Lxx forum in hopes that your question about boot mode will get answered more quickly there.

Hi DT

I see that David has moved a couple of threads from you from the BIOS forum to the device forum. 
I do think the issue you at hand is resolved if you were to use emulation boot mode, as it is in this boot mode both ARM and DSP are left enabled by default and spinning in a while 1 loop making CCS based debug easier

The emulation boot is documented both in the bootloader application note, and a brief description is provided in the following wiki

http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader#When_should_I_use_Emulation_Boot_Mode.3F

It is likely that when you were using any other boot mode, if you do a system reset or a power on reset, if you had both the DSP side and ARM side debugger open and connected, then DSP will go back to is power on reset state of being clocked off and disabled , that could be tripping or messing up your emulator. 

If you only had the ARM side CCS up and DSP powered off and not in use and still saw some issue, then it could be something else. 

To eliminate ARM/SYS BIOS or NDK as an issue, you could see if it is easier for you to debug any other ARM side project, that could be part of the LogicPD BSL, Starterware, or packages like quickstartrcsl etc.

Hope this helps.

Regards

Mukul 

Thanks for your reply. I'll check the wiki link :)

Hi DT,

Have you figured out the answer to this problem yet?

I found this same problem nearly a year ago...the thread link that I brought it up in looking for help follows...

http://e2e.ti.com/support/embedded/bios/f/355/t/92382.aspx?PageIndex=2

I found identical results to yours -- not working on the ARM core, but working on the DSP.  However, I have some serious DSP work needed in my product so I cannot use that core for communication too!  I'm also using SYS/BIOS on both cores.  I had asked a final question on my post there, but never got a follow-up response if it was a bug or not, and my issue was closed.

The workaround given at that time was to reset the ARM using the emulator before running the NDK example app on the ARM, but that only allowed me to continue my development of my product.  Now I'm trying to do a power-on boot of my product and don't have that luxury, since the only computer interface in my product is TCP/IP and the problem remains.  So again, I am trying to figure out what is going on.

I see your last post in early January was that you were going to try some other example programs--did you try that?  That exercise didn't show me anything other than the simple programs work on both cores.  I don't remember if the other SYS/BIOS examples worked on the ARM or not (if I remember right, they didn't on the L138 ARM), but running those didn't give me a clue on how to fix the original problem.

What I see now that I'm more familiar with this processor is that when the NDK is started on the ARM core without the reset, when I break execution it ends up with the PC at low addresses (below 0x01000000) -- where no valid memory exists.  It looks like the vectors at 0xffff0000 are configured correctly though.  Another thing I found, was when doing a SW reset instead of a HW reset on the ARM using the emulator, it branches to 0x00000000 instead of 0xfffff0000 which could also explain why I see it trying to execute in low memory, but I don't know what the difference is when the emulator does a SW boot or a HW boot!  I also thought a clue might be in the L138 errata Section 2.1.10 where the VSR was not initialized, but after taking various register dumps during emulator boot and power-on boot, I don't think that is the problem either (I'm not positive though).

I see that this issue is now tagged as answered,  Is it?  I don't see an answer, only that you'll try to look into the examples further...  If it is answered, will you get notification that I replied to you?  If it is resolved, where do I find the resolution?  Please reply to this thread to acknowlege that you received my questions.  I don't know if the thread is dead once its marked answered...

Roy

Hi,

sorry for the delay. Yeah, I got the notification when you posted. I'm out working on another project at the moment so I can't really try a lot. If I recall, I found why the applications were not running, but didn't go deep in this. It was because of the Boot Mode on the eval board. I still don't know why I needed to use the Debug Mode (Boot) instead of the SPI Flash one.

And since I got off the project for an urgency at that moment, I haven' try booting the application on the SPI Flash with the SPI Flash Boot Mode, so I don't know if it will work. I'll gladly look for more answers when I'm back to this project.

Feel free to keep me posted!

Thanks,

DT