Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

I found and old backup where SpiWriter still works. Got my application code loaded into SPI NOR flash. I will try to load u-boot with it and see if I get a prompt.

Uboot won't load (SPI mem = 0, i.e. says file too big on load of UBL)
Backup code was NOT the solution. Recent code (blinking led on GPIO pin with simple loop delay) was loaded with newer code. Works SOMETIME. i.e didn't work, tried to run in debugger, listed errors, reset debugger, ran in debugger ok, tried SpiWriter again and it loaded. Tried uboot load and it failed. Went back to run blinking led in debugger and it failed. Won't initialize ddr memory? This is basically running the Device.c (Uint32 DEVICE_init()) code, before it even gets to my code.

The problem seems somewhat random. Debugger problem? Carrier board problem (the engineer denies the possibility).

Thinking that I am not getting an interrupt mainly because I have no down count (registers read 0 on break). No PLL0_AUXCLOCK? If u-boot runs on the timer for polling schedules, this might explain why it never sends out a serial message on loading with sfh. Not sure what this DDR problem is but it also might be due to input clock problems? ANY suggestions on this will be gratefully received.

Hello,

So I'm struggling a bit to get the full picture of what is going on.

Are you saying that you are running the sfh* program to put both the Critical Link supplied uBoot.bin (second stage) and the UBL_SPI_MEM.ais (first stage) bootloader code back into the SPI NOR boot area and it no longer is able to boot to the uBoot prompt (with no debugger in place)? If that is the case, there may be some sort of issue there and we should consider putting an RMA in place. Are you sure that, during the spi_writer approach, you are first giving it the UBL file before the uBoot.bin file?

Keep in mind how the AM1808/OMAPL138 processor boots normally (not with bare metal Starterware code). First the UBL is loaded into on chip SRAM. UBL reads the I2C factory prom to get the proper module memory configuration and speed grade, adjusts the core voltage power supply via I2C, then configures the main and aux PLLs and sets up the DDR per our tested PHY configuration settings. After that, the UBL loads uBoot.bin into DDR and transfers control to uBoot.bin, which is pretty much completely polled. No interrupts are enabled. No peripherals are enabled beyond the UART unless an IO command is in use (e.g., tftp enables the network long enough to do the tftp command, then shuts it back down).

At this point, the DDR and all of the basic clock tree is setup, and transitions to linux have been well tested. Customers developing linux apps don't have to worry about configuring the PLLs or the DDR, in general, or ensuring the low level boot sequencing and power supply controls are working correctly.

Pure Starterware code, on the other hand, requires the application developer (you) to make sure that you perform all of these UBL functions at the beginning of your application. This is because the flow from TI has it replacing the functions of both the UBL and the uBoot.bin code. I believe they encode the PLL and DDR settings as part of the AIS initialization header words so that you can load the rest of your application to external DDR. If this isn't correct, then the DDR may be flakey, or may not function at all. Same for any PLL configuration. This could very much irritate a debugger the way you describe. That's why we promote letting UBL / uBoot.bin load and had uBoot load your baremetal code. This let's you skip dealing with the DDR and PLL setup and focus on your application.

Are you pushing to a pure Starterware primarily due to a boot time requirement?

-Mike

Mike,

Thanks for the description. I think your confusion is more about not understanding why it doesn't work (like me), not my description. I probably should not have confused the issue by adding the issues from debugging. But that MIGHT be a clue. I have solved/eliminated some of them by lowering TCLK again, from 400kHz to 250kHz.

Yes, my project is trying to duplicate the UBL startup in a standalone application. I realize that nobody else does it and it is both for fast startup, memory space, and to learn ARM well enough to solve problems in an application that will stress it's capabilities (if I can get there). But that is not why I am asking for help. I am asking for help because known good Critical Link code in not working (apparently)

The reason I am making this question is that, I can:

1: Load my application and see that flash is programmed (blinking light occurs, very fast startup.
(uses boot.asm (__int_c00) and device.c (DEVICE_Init() for initialization)
2: Switch to UART boot.
3: Load UBL and u-boot using "sfh_OMAP-L138 -flash -v -p COM2 UBL_SPI_MEM.ais u-boot.bin". As reported in the file attachment, there is NO indication of a problem in the SPI Flash programming load.
files are exactly as downloaded in the CriticalLink zip file, in a separate directory. Command line is given in a Dos Box.
4: Switch back from UART boot to normal boot.
5: Start up COM2 for communications.
6: Observed no uboot prompt. Tried to enter a key in case it is just glitched. No response. Nothing. Cycled power. No response.

Since I can see the ROM prompt (BOOTME) on COM2 (UART1) output, I assume that the UART1 hardware is working fine. Since the code and SOM board is ENTIRELY from Critical Link (known good) and follows "reprogramming a dead board" to the letter, it SHOULD be working. I have reprogrammed the board several times in the past and it has always worked then

I know that I am replacing/erasing SPI flash because my custom code does not start (no blinking light). It looks to me as if I am loading the UBL/u-boot just fine but it is not running for SOME reason. This, to me, points to a hardware issue, either on the SOM or possibly due to some hardware interference with the 200 pin connector to the carrier board. It supplies power only, but has connections to the I2C, etc. I have included my pinmux setup header file.

Imported and ran UBL to CCS 6.1.2. Changed only DEVICE_UART_PERIPHNUM to 1 from 2 in devices_uart.h to get UBL messages out. They do not show up on UART2 when I boot from SPI-NOR FLASH.

It apparently initializes ok, copying u-boot image from SPI (loaded by sfh as reported earlier) which then runs! And outputs on COM2 as expected. NO output on UART1 or UART2 when booting from SPI. Why? What am I missing?

ALSO note that I am worried about the message "error reading I2C Configuration Block". Is this some carrier board peripheral it is expecting? I expect the message about no ethernet PHY. We haven't added that to the carrier board yet.

===========================================
AM1808 initialization passed!
Booting TI User Boot Loader
UBL Version: 1.65
UBL Flashtype: SPI
Starting SPI Memory Copy...
Valid magicnum, 0x55424CBB, found at offset 0x00010000.
DONE
þumping to entry point at 0xC1080000.

U-Boot 2009.11 (Mar 31 2011 - 19:39:18)

I2C: ready
DRAM: 128 MB
NAND: 0 MiB
MMC: davinci: 0
In: serial
Out: serial
Err: serial
error reading I2C Configuration Block
ARM Clock : 456000000 Hz
DDR Clock : 150000000 Hz
EMIFA CLock : 24000000 Hz
DSP Clock : 456000000 Hz
ASYNC3 Clock : 228000000 Hz
Enet config : 2
MMC 0 Enable : 0
Resetting ethernet phy
Net: No ETH PHY detected!!! ==============================

Well, it worked for two or three runs. Now it hangs on the uart initialization? Thinks that the uart is busy with output. Got to be hardware? Too erratic to be software? Software generally goes wrong EVERY time if there is a problem. But it could be the debugger/drivers? Two different TMS100v3 (olimex) have the same problem but the continual reduction in TCLK has me wondering. It sometimes hangs with the 'circling cursor' and I have to reboot to get going again.

Ian,

Can you let us know if the behavior changes when this module is used in the Industrial IO Development Board (80-000268) assuming you have one? I believe all of your testing has been done with/in your own custom carrier board correct?

Additionally do you have a second module with which you can attempt to reproduce the problems you are experiencing or is this the only module you have?

Please feel free to provide the serial number from the label of the module and I can check into the warranty status of the module with our production team.

Thank you,

Alex

I don't have either a second (working) module or a standard carrier board. We couldn't afford them when we started and our finances have not improved noticeably. That is why I am trying to eliminate debugger, host system, etc in diagnosing this (loading uboot, comm over serial port). It SHOULD have worked. I am baffled as to why it doesn't. No way to swap with 'known good' to isolate cause by following failure. Only the Carrier/SOM board is involved in u-boot startup. I wish I could isolate the SOM, but I need the carrier to supply 3.3v for power.

Risk analysis is:

1: JTAG debugger (two units, no noticeable difference in operation so unlikely to be cause). Removed for uboot operation anyway
2: SOM board (replaced (Feb 18) recently after power supply failure so little history to give confidence). Only started trying to debug in first or second week of March and assumed the problems were from coding or debugger (replace it, TMS100v3, later assuming that it was damaged by power supply, but turned out to be bad connection, fixed).
3: Host system (rebuilt from ebay parts after failure of stock CPU cooler). Everything seems to work BUT it reports only 2/3rd of the memory (two of three channels of memory?). Possible problem. Will be able to put together second system in early May, but not now. Cannot explain failure of u-boot as not involved except to run serial port and that is working on 'BOOT ME'.
4: Carrier Board (no evidence and it was ok for a long time. Rebuilt after power supply failure that destroyed the first SOM module. Hardware developer denies that it COULD be a problem. He is very good, so I believe him, especially as we had no problems before the power supply failure that destroyed the first module.

Seems to be some sort of random startup problem? Clocks? NOT may code as this is compiled code from Critical LInk. The debug problems may be a SYMPTOM of the problem on the board? The power supply and host system failures cost money and time I didn't have, so I am a bit desperate.

Ian St. John wrote:

ALSO note that I am worried about the message "error reading I2C Configuration Block". Is this some carrier board peripheral it is expecting? I expect the message about no ethernet PHY. We haven't added that to the carrier board yet.

The i2c config is a eeprom on the SOM, hooked up to the i2c0 bus. It is used to save information about the SOM and is used by the UBL/u-boot to determine how to configure the module. It holds the SOM model number, mac address, serial number, etc. Could your baseboard be interfering with the i2c0 bus? Or i2c addresses 0x50-57?

===========================================
AM1808 initialization passed!
Booting TI User Boot Loader
UBL Version: 1.65
UBL Flashtype: SPI
Starting SPI Memory Copy...
Valid magicnum, 0x55424CBB, found at offset 0x00010000.
DONE
þumping to entry point at 0xC1080000.

U-Boot 2009.11 (Mar 31 2011 - 19:39:18)

I2C: ready
DRAM: 128 MB
NAND: 0 MiB
MMC: davinci: 0
In: serial
Out: serial
Err: serial
error reading I2C Configuration Block
ARM Clock : 456000000 Hz
DDR Clock : 150000000 Hz
EMIFA CLock : 24000000 Hz
DSP Clock : 456000000 Hz
ASYNC3 Clock : 228000000 Hz
Enet config : 2
MMC 0 Enable : 0
Resetting ethernet phy
Net: No ETH PHY detected!!! ==============================

Thanks. You got it.

Only way to be sure was to cut the i2c traces on the carrier. Biked over to my partners and got him to test it. Guess what? Cut the I2C and it worked.. I had thought that the "I2C: ready" was the eeprom read and that "error reading I2C Configuration Block" just meant that it had failed to read some standard peripheral (i2c controller for gpio?) that we don't use.

My development is for a high speed data acquisition system which is why we need a custom carrier for the codecs. So for now, just MMC/SD (no card installed yet), UART (working as shown by BOOTME) McASP from the Codec (clock is 24.576 MHz external for low jitter but not configured on ARM yet so shouldn't be an issue) and I2C to set up the codec. We had thought that the codec had not been harmed but maybe it was and that was messing up the I2C signals. So, the problem was:

No configuration read, ergo bad setup of board, timing messed up so JTAG has problems and uBoot failed on startup.

Again, thanks to all who contributed. Consider it resolved.

OMAP-L138/AM-1808/AM-1810 initialization passed!
Configuring 128MB mDDR
Booting TI User Boot Loader
UBL Version: 1.65:2.28.1 BuiltJul 11 2011 12:49:53
UBL Flashtype: SPI
Starting SPI Memory Copy...
Valid magicnum, 0x55424CBB, found at offset 0x00010000.
DONE
Jumping to entry point at 0xC1080000.

U-Boot 2009.11 (Mar 31 2011 - 19:39:18)

I2C: ready
DRAM: 128 MB
NAND: 0 MiB
MMC: davinci: 0
In: serial
Out: serial
Err: serial
ARM Clock : 300000000 Hz
DDR Clock : 150000000 Hz
EMIFA CLock : 100000000 Hz
DSP Clock : 300000000 Hz
ASYNC3 Clock : 150000000 Hz
Enet config : 2
MMC 0 Enable : 0
Resetting ethernet phy
Net: No ETH PHY detected!!!

U-Boot >