• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 478 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C5502 UART bootloader difficulties

Ben Supper
Prodigy 50 points

I'm having a few difficulties getting the UART bootloader to work on a C5502. Having investigated quite deeply for a couple of days, I have found out where the problem is: the device is programming itself via UART without a hitch, but not calling the entry point.

The boot table is fine: in fact, I can blow the same file to an EEPROM and boot using SPI, and it works wonderfully. The integrity of the data we're sending has been checked time and time again: the UART behaves as it should, with the TX pin echoing the RX pin but trailing by eight bits. The GPIO4 pin also does what it should do. We have a weak pull-down on it, and see a positive-going pulse on it as soon as the last byte of boot data is transferred.

The first few bytes of the boot table look like this:

00 00 7B 2F : entry point 0x7b24 (yes, this connects with _c_int00)
00 00 00 00 : register configuration count = 0
00 00 00 32 : data block count 0x32
00 00 7B D4 : start of data 0x7bd4
[... 50 bytes follow ...]
00 00 04 5F : data block count 0x45f 
00 00 77 20 : start of data 0x7720

... and it goes on in a similarly understandable way.

Owing to the way the debugger works, I cannot interrogate any memory address lower than 0x00c0 without it complaining, so cannot inspect the supposed entry point at 0x0060.

I've tried with another program and get the same result: all programmed properly, everything behaving as it should, but the program counter is hovering around 0x0030 and not going to the entry point as it should.

The .cmd file is:

-heap 0x1000
-stack 0x1000
-sysstack 0x1000

MEMORY
{
  MMR   : o = 0x000000 l = 0x0000c0
  DARAM : o = 0x0000C0 l = 0x00FD40
  VECS  : o = 0x00FE00 l = 0x000200
}

SECTIONS
{
  .cinit  > DARAM
  .text   > DARAM
  .stack  > DARAM
  .sysstack > DARAM
  .sysmem > DARAM
  .data   > DARAM
  .cio    > DARAM
  .bss    > DARAM
  .const  > DARAM
  vectors > VECS
}

Any ideas?

Chip markings (just in case this is a known issue with some dodgy ROM): TMS320C5502PGF CA-32AZKRW G4

  • 0
    Prodigy 50 points

    Supplementary information:

    1. Changing the start address to 0xFE00 (the reset vector) doesn't fix the problem.
    2. The same issue is present with I2C booting: it programs OK; GPIO4 is happy throughout and programmed memory verifies; it won't execute.
    This seems a bit odd, especially since SPI works fine, which points away from a problem with the .bin file. Has anybody got these boot modes working, or seen these problems before?
  • 0 in reply to Ben Supper
    Prodigy 50 points

    We've fixed it.

    In case anybody out there has the same problem, we had to go through these diagnostic stages:

    1. Create a simple 'flashing LED' project: no interrupts or timers or PLL. This programmed fine.
    2. Disassemble the bootloader and watch it running. The 'branch to entry point' occurs at 0xFF809D for I2C. Realise that it was picking up the entry point from the 16th byte of the file onwards; not the initial byte as it should have.
    We tracked it down in the end to a corrupted CCS project: deleting all the project files and building them from scratch created a radically different .bin that now programs, and the entry point is picked up from the correct place.
    All the source files, .cmd file and so on are the same: the CCS project had somehow corrupted in a way that did not manifest in the debugger or the SPI boot mode.
  • 0 in reply to Ben Supper
    Prodigy 50 points

    ... and there's more. This problem recurred. The memory address that the device would jump to just happened to be the contents of memory location 0xC0, the first bytes after the memory mapped peripheral registered (according to the datasheet).

    Changing the linker file to move the start of program DARAM from 0xC0 to 0x100 fixed the problem.

  • 0 in reply to Ben Supper
    Prodigy 50 points

    Got there in the end. Bottom of Section 2.6.1 of spra911c:

    'To avoid corruption of these memory locations, the sections contained in the boot table should not contain any destinations lower than word address 0090h (byte address 0120h).'

    Mis-reading word addresses as byte addresses, and not realising that the bootloader wrote and interpreted the lower locations of RAM to its own ends ... I hope these findings are useful to somebody else, because they utterly did my head in.

    I wonder if it might be worth somebody at TI putting a note to this effect in the linker script files? How many hundreds of pages have I read to chance upon this troublesome paragraph?!