Hello,
I am developing software for a custom board that has uses an OMAP-L137. We are planning on using SPI flash for booting. We also have a custom breakout debug board that we can connect directly to the SPI bus for the flash, and I can connect and successfully erase/read/write to the chip (W25Q32) with a generic, 3rd party SPI flash programmer.
I do not want to use an OS of any kind at this point. All I want to do right now is get the DSP to run code to make an LED blink, which is proving to be extremely difficult on this device. My problem is twofold: I cannot run the code through a CCS debug session, nor can I have the code run from simply booting off an external memory. I'm mainly looking for answers about the latter. I'll describe what I've done thus far:
I have verified the power/reset sequencing already, CCS' JTAG self-test (xds100v2) passes, and I can scan the jtag chain and read the correct device ID from the omap.
CCS:
I can connect to both cores of the device over jtag in CCS. As previously stated, I only care about the DSP at this point. When I connect to the DSP, it says that it's suspended, which is to be expected since there's no code to run initially. I can run the debug_gel file that is provided on the wiki, and I can read relevant values in memory (bootcfg, bootrom ID, etc.), and they all look good. However, when I try and load the ".out" file (by doing Run --> Load --> Load Program), I get a data verification error: "C674X_0: File Loader: Verification failed: Values at address 0x80010800 do not match Please verify target memory and memory map." 0x80010800 is the start of the .text section of memory. From reading other forum posts, it seems this error has to do with the memory map that the GEL file sets up. The default .cmd file for the OMAP-L137 seems to put everything in shared memory (i.e. 0x80000000-0x8001FFFF), and the given GEL file seems to not map that section of memory. I've tried adding it, and it made no difference. Also, there really doesn't seem to be much information (a checklist of some kind) as to what the GEL file actually needs to do to get the chip up and running. Should the code be put in the shared memory, and is there anywhere else I can put it?
BOOT:
Naturally, since CCS is misbehaving, I tried to create an image to put in flash, and have the chip boot on power-up. Right now, I have basic code compiled with CCS to set some output pins (LEDS) high (i.e. setting the direction bits to 0, writing to the set_data register, and then sitting in a while(1) loop). I have run it through the AISgen tool, and have configured the PLL, PSC, and Pinmux correctly in AIS (so I shouldn't need to do it in my code). I write the AIS .bin file to the SPI flash chip (starting at address 0), disconnect all the debug/probe boards, and then power cycle. The pins do not change from their respective pulled-up/pulled-down values, so it seems that the code has not run. The boot mode is latched correctly, the pin mux values are what I expect, and I can probe on the SPI bus and can see the data being read out of the flash. So it seems that the AIS portion has been run, but something has screwed up when it jumps to the application code. Am I writing the AIS bin file to the right location in flash? The "Jump & Close" command seems to be jumping to _c_int00 - is this correct? Is there a detailed document for the DSP bootloader (describing exactly how it works - I've already read "Using the OMAP-L1x7 Bootloader")?
I have read through every wiki page for the omap and searched through the e2e forums numerous times, so PLEASE do not respond with a wiki/thread link, and nothing else. I've been banging my head against this for over a week, and have not gotten anywhere. It does not seem like a hardware failure, since I can communicate with the chip and all the diagnostic information looks good.
Thanks,
Dave
