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.

Boot-load an empty TIVA vs calling ROM_UpdateSSI() or using boot_serial

Other Parts Discussed in Thread: TM4C123GH6ZRB

Szenario:

We have an imx6 running Linux and a TIVA TM4c123gh6zrb on the same custom board - connected via SPI (spi0).

We want to bring up the system after being manufactured with as few preprogrammed components as possible and with no "external Connections" (like jtag, programmers etc). This is why we investigate the various possibilities to "self-Flash"/update the TIVAs.

what we've archieved:

- adapted the boot_serial code to use SPI instead of UART

- created a Linux tool to talk to boot_serial via SPI. employing a bootloader requires us to "Offset" our app-code to go after the bootloader. this is working as expected

- created a custom TIVA app (based at flash-start/0) that can be switched to "upload mode" via SPI, the TIVA-app then calls ROM_UpdateSSI(), on the Linux end our tool then sends boot commands, also working as expected

"working as expected" means: we can ping, get Status, upload a new application and reset. the new application then starts as expected.

 

And now the issue:

if we erase the entire Flash via LMflash and start our Linux tool, we can talk to the TIVA as before (ping, Status, upload, reset ...)

EXCEPT the uploaded application isn't programmed into Flash - so after we do a reset, the TIVA still finds it's Flash empty and again enters boot-mode.

What is wrong with our thinking?

 

  • Hello Markus,

    When you mentioned that you have erased the entire flash, then did you upload the modified flash based boot loader to location 0x0. And while doing so did you send the download command with the Start Address as 0x0 and Size of the image

    Regards
    Amit
  • Hi Amit,

    please reread my initial post:

    • i have no problems whatsoever when using the flash-based bootloader or when calling ROM_UpdateSSI() from _my_ application, obviously: if i'm updating the flash bootloader, it is programmed to 0x0 (with proper size) to answer your question
    • the download start address i send (and the application offset configured when compiling in ccs) obviously depend on the type of application: 0 for the bootloader, 0x2800 for the application, length is matching the data (and obviously is correct as it works with flash-base/ROM_UpdateSSI())

    The issue i'm having is when i'm trying to flash an _empty_ TIVA. I do get the ACKs from the CPU, flash is erased but nothing is _written_ to flash! Protocol and application on the programming host is the same.

    There seems to be a similar issue: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/431518#pi239031349=2

    There you're referencing SPI timing (CS going inactive between byte-transfers or not ...). Is the required protocol/timing described somewhere in the datasheets? Is there a protocol spec for the transfers apart from the informal description in the "TivaWare Boot Loader" PDF.

  • Hello Markus,

    We are working on improving the documentation for quite some of the items in TM4C12x devices including the boot loader.

    Coming to the issue at hand. if the Tiva is empty then you cannot know if it is erased or not. On the other thread the user never came back with the analysis of the issue (except changing the mode). I would have to ask for the same data from you.

    Regards
    Amit
  • Hi Amit,

    yes i can: i'm using LMFlash to read the FLASH: it's all (still) set to FF - which i would call erased.

    again, steps are as follows:
    - program an application
    - activate bootloader or start ROM_UpdateSSI()
    - update runs
    - flash updated, the app starts

    - erase flash using LMFlash, thus forcing TIVA into ROM bootloader
    - update runs, all ACKs ...
    - read flash with LMFlash: still completely empty

    BTW, i'changed from SPI_MODE_0 to SPI_MODE_3: no difference
    Also using different SEND_DATA block sizes: 1, 8, 128, 240 no difference (all ACKS)
    SPI protocol toggles CS after every byte ...
    Inter-byte delay: don't know. do i really have to measure it? btw, if the tiva ACKs the (checksummed send-) packets, i would suggest it transfer is ok and the TIVA can keep up with the speed ...

    BTW, can't you just give the _requirements_ for spi-mode, cs-toggling and interbyte delay instead of asking what i've tried?

    The main question for me still is:
    - it does work with ROM_UpdateSSI() and boot_serial, but
    - the ROM-bootloader does not write flash, although all protocol-answer suggest ACK/OK
  • Hello Markus,

    I can understand your frustration on the same not working. But without having an exact setup as yours I need to trouble shoot the same before. Note that there are multiple clocking options as well. It would help me better to debug the issue if I can get as much info as possible first

    1. Is there a main oscillator on board. If yes, then what frequency of crystal
    2. What is the SSI Serial Clock rate being used?

    Regards
    Amit
  • ad 1) yep, there's a 8MHz oscillator for the tiva
    ad 2) spi clock is configured to 100kHz on the linux side

    i'll mesure the SPI clock speed tomorrow - otoh why would the tiva ACK a checksummed 240 byte send_data packet if there were communication issues?

    i've sent the source for our upload tool to jamal karim - he will share it with you ...
  • Hello Markus,

    100KHz should be good and indeed an ACK would represent an accepted packet. Considering all the other experiments, it should have worked. Awaiting the files to inspect.

    Regards
    Amit
  • Hey Amit,

    i'm still seeing (repeatability) issues - most probable related to protocol timing - but i'm getting somewhere ...

    Did you get a chance to look at the issue?

    Cheers,

    Markus

  • Hello Markus,

    I received the files and they seem to be running on a Linux machine which i do not have.

    Also as you mentioned it works when using the Application call to ROM but not when booting directly from ROM, would imply that a timing issue may not be there especially if it is running at 100KHz.

    Regards
    Amit
  • Hi Amit,

    yes, it's linux code - pls see board description/first post.

    @timing: i can make it work against ROM-only boot code now by enabling more verbose debug output ... sounds like timing to me ...

    Markus

  • Hello Markus,

    Adding the verbosity would imply more time between packets (something that did not work earlier as you reported.)

    Regards
    Amit