• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 648 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-OMAPL137: OMAPL137 ARM UBL FlashAndBootUtils UART Debug

Hoffiz
Expert 1670 points
Part Number: PROCESSOR-SDK-OMAPL137
Other Parts Discussed in Thread: OMAP-L137

I'm testing the ARM UBL Code from OMAP-L137_FlashAndBootUtils_2_40. I have created a new project in CCSv*, under a linux host, and I'm trying to step through it and debugging. I'm expecting to see a stream of data out of UART2, P1 on the Spectrum Digital EVM. I'm confident the project is configured properly. The spectrum digital is in Emulation boot mode and from CCS I can launch the target, connect to the DSP, then connect to the ARM, load the ARM UBL program and step through it. I can see the entry point "boot" and the code pauses in main() at ubl.c to allow me to step-through. 

Even before I can test the UBL works correctly I'm stuck receiving: DEBUG_printString((String)devString);

I've tested on a Windows machine using Putty and on a Linux host using minicom. In both cases I ensure I configure the host to: 115200, 8 bits, 1 stop bit, no parity, no flow control. Following:

I'm using a DB9 to USB converter which I have tested works if I change the bootmode to UART and I can see BOOTME on the screen. I've confirmed the adapter is at /dev/ttyUSB0 and sometimes can see 1 char. Initially a "O" and then changed it to "Hello" and can see an "H".

The code gets stuck here:

do
{
status = (UART->LSR)&(0x20);
timerStatus = DEVICE_TIMER0Status();
}
while (!status && timerStatus); <----- status is 0

where: 

LSR unsigned int 0x00000000 (Hex) 0x01D0D014

Here is a dump of the UART2 registers:

*(UART) struct _DEVICE_UART_REGS_ {RBR=0x00000000,IER=0x00000007,IIR=0x000000C1,LCR=0x00000003,MCR=0x00000000...} (Hex) 0x01D0D000 

RBR unsigned int 0x00000000 (Hex) 0x01D0D000
IER unsigned int 0x00000007 (Hex) 0x01D0D004
IIR unsigned int 0x000000C1 (Hex) 0x01D0D008
LCR unsigned int 0x00000003 (Hex) 0x01D0D00C
MCR unsigned int 0x00000000 (Hex) 0x01D0D010
LSR unsigned int 0x00000000 (Hex) 0x01D0D014
MSR unsigned int 0x00000000 (Hex) 0x01D0D018
SCR unsigned int 0x00000000 (Hex) 0x01D0D01C
DLL unsigned char 0x51 'Q' (Hex) 0x01D0D020
RSVD1 unsigned char[3] [0x00 '\x00',0x00 '\x00',0x00 '\x00'] (Hex) 0x01D0D021
DLH unsigned char 0x00 '\x00' (Hex) 0x01D0D024
RSVD2 unsigned char[3] [0x00 '\x00',0x00 '\x00',0x00 '\x00'] (Hex) 0x01D0D025
PID1 unsigned int 0x44141102 (Hex) 0x01D0D028
PID2 unsigned int 0x00000000 (Hex) 0x01D0D02C
PWREMU_MGMT unsigned int 0x0000E002 (Hex) 0x01D0D030
MDR unsigned int 0x00000000 (Hex) 0x01D0D034

Any suggestions will be welcomed, I'm suspecting the adapter.

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the sw team. They will post their feedback directly here.

    Best Regards,
    Yordan
  • 0
    TI__Guru** 114410 points
    Hoffiz,

    I may have mentioned this on one of our earlier posts but the ARM UBL in serial flashing tools is not he code you should be using for new development. This was created at a time when we supported Monta-VIsta Linux in 2009 time frame. We recommned that you use UBL base line in the Linux PSP releases that are provided here:
    processors.wiki.ti.com/.../DaVinci_(ARM9)_PSP_Releases

    Also, note that OMAPL137 is a DSP boot master device, which means that on POR DSP boots first and then wakes up the ARM to start execution so debugging ARM UBL independent of DSP UBL may not give you the full story as the DSP UBL may be performing some initialization which you may be missing in the ARM UBL. At a high level the process is described here:
    processors.wiki.ti.com/.../f1260923904-705387572.html

    Regards,
    Rahul

    PS: I am closing this post as we don`t intend to support this legacy usecase for any newer designs.
  • 0 in reply to Rahul Prabhu
    Expert 1670 points
    Thanks Rahul, I appreciate your patience. I have already migrated to use the DaVinci (ARM9) PSP that supports the OMAPL137. I'm able to successfully compile the project using the latest compiler. After carefully building a project for the BOOT_SPI configuration I'm able to launch the debugger and step through the code.

    In a previous post you kindly suggest I download: CCSv5/CCSv6 that shipped with the older TI ARM compiler cl470. Is there any chance I can install that version from inside CCSv8 under Linux? I would also appreciate if you can point me in the right documentation to find the expected version, I have looked and could not figure it out.

    I don't think a new compiler is the reason for being stuck (my goal is to see some DEBUG String on the UART2 port) but I still can't see the DEBUG streams. The only change I had to do was changed the linker cmd file from -e _boot to -e boot.

    The other problem could be what you are suggesting that running the ARM UBL in isolation, assuming the DSP GEL gets me there is incorrect. I have tried running it setting the bootmode to emulator and spi0. I also understand that I won't be able to run the entire UBL but I would expect at a minimum, I should be able to see some DEBUG Strings and the stop before the SPI COPY.