Field firmware upgrade via SSI

Hello Bradley,

This application note and the associated example code-application code would be just the right match

www.ti.com/.../spma074a.pdf

Amit,

I've read through this application note several times now, but can't see any SSI waveform examples or references to my questions. Can you please ping your engineering team for this info?

Regards,

Brad

Hello Bradley

The Boot loader procedure for the 3 serial interfaces of I2C, SSI and UART are almost the same. Figures 12-15 give the flowchart of the flow that the controller must execute. Did you check the software example and PC application that comes along with this application note?

I am not sure how a waveform would be useful, since a typical firmware upgrade takes a second and compressing the same into a waveform would obscure any usable information.

I would suggest using the software example and the PC application to monitor the SSI line during a firmware upgrade so that you can implement the same process on other uC which will work as the upgrader.

A waveform of a command and response packet transmissions would be extremely helpful, seeing as I've written my own SPI master controller to communicate with the Tiva SSI port 0. I can only guess at the chip select setup and hold times, and whether the chip select can be de-asserted between a command and response pairing. This is likely documented with your engineering team.

Acquiring a demo board, setting up your demo program and probing the signals is a bit arduous for me...

I would also like to confirm the CPHA and CPOL settings.

Regards,

Brad

Hello Brad

I have used both Mode 0 and Mode 3 for programming via the SSI master on the EK-TM4C123GXL.

Acquiring it is a few days and since the binary is already provided along with the source code, it should be easy enough to setup a golden setup.

I'm still waiting on your engineering waveforms.

Hello Bradley

Any specific command and response packet?

Ping would suffice.

Tx,

Brad

Hello Bradley,

Attached is a snapshot of the PING command

Yellow: SSICLK

Green: CS

Blue: Master Out Slave In

Pink: Master In Slave Out.

Thanks, Amit.

I can't quite make out the first four bytes sent. Could you please zoom in?

Is chip select de-asserted after every byte sent?

I'm curious as to why the ACK isn't sent until the 11th byte. Is the master supposed to continuously poll until received?

Tx,

Brad

Hello Brad

The first 4 bytes are 0x03, 0x20, 0x20, 0x00. The pulse on the MOSI is during the time when there is no CLK and FSS is high. The CS can be kept low.

The master is supposed to poll the slave till a response comes.

I'm at a loss, Amit. The bootloader simply won't respond to my pings. See attached logic analyzer capture.

mode = 0
f_sclk = 1MHz

Do I need to do anything other than call ROM_UpdateSSI() for SSI0?

Regards,

Brad

Hello Brad,

Are the GPIO pins and SSI peripheral configured correctly before the execution of ROM_UpdateSSI?

Yes; I actually trigger the call to ROM_UpdateSSI() from a command via the SSI0 port. I can break on ROM_UpdateSSI() before stepping in and losing all intelligible debugging.

Is there a way to link the debugger to the ROM_UpdateSSI() source?

Tx,

B

Hello Bradley

No. The ROM functions disassembly is not part of the TivaWare package.

Also how long does the master device poll the slave device?

I have a 2 second timeout.

Can you provide me with the source, so I can continue to debug?

I'm blind, otherwise.

B

Hello Bradley

Source for the master side or source for the ROM_UpdateSSI?

ROM_UpdateSSI()

Tx,

B

Hello Bradley,

I am sorry. The source code for the same comes along with TI proprietary information and cannot be released.

Amit,

I've managed to get a ping response and narrow down the issue a little more. I can only get the Tiva to enter SBL and respond when debugging. Is there something the debugger is initializing that I'm not? Unlocking flash perhaps?

Regards,

Brad

Hello Bradley,

That should not be the case as we have run automated test of the ROM based boot loaders and never had to connect a debugger

Often - when only the (attached) JTAG pod seems to restore operation - it is the absence of proper (non-MCU/internal) pull-up resistors - which causes such issue... Internal resistors are too high in value to (always) succeed - the pod (or properly valued (external Rs) corrects...

Also in the realm is the treatment of MCU Reset - which (again) is impacted by the pod...

The JTAG adapter has been connected in both the "load application from debugger and run" and "run application from flash" scenarios.

I (incorrectly) believed that the JTAG pod was being connected/disconnected. I wonder now if your issue involves a failed, "Program Start Sequence" - but we've NO experience w/this vendor's MCUs in this mode...

Whenever I debug load or boot the application from ROM, I consistently get a FaultISR() after executing ROM_UpdateSSI(). While debugging, if I break on the FaultISR() loop and restart the debug session, ROM_UpdateSSI() is happy and responds to my SBL pings.

Makes no sense to me, but I'm sure someone at TI knows what the difference is.

B

Hello Bradley,

That is a good sign. If it is going to the FaultISR what does the NVIC_FAULTSTAT and NVIC_FAULTADDR show the cause of the fault?

NVIC_FAULT_STAT = 0x00060000
NVIC_FAULT_ADDR = 0xE000EDF8

Disabling interrupts seems to have solved my problem, Amit. Tx.

Did I miss this nugget of information somewhere?

B

Hello Bradley

Both. No, you did not miss this information as it is not clearly documented and Yes, if you would have looked at the example codes this would have been evident.

In the example, interrupts are enabled right before calling the updater...

usb_dev_sbl.c:1704

//
// Re-enable interrupts at the NVIC level.
//
ROM_IntMasterEnable();

//
// Call the USB boot loader.
//
ROM_UpdateUSB(0);

Hello Bradley

I guess you did not see the lines just above it. All interrupts are first disabled in the NVIC. Just enabling the ROM_IntMasterEnable will not cause all interrupts to be enabled. it will only allow the interrupts when enabled to be recognized by the CPU.

//
// Disable all processor interrupts. Instead of disabling them one at a
// time, a direct write to NVIC is done to disable all peripheral
// interrupts.
//
HWREG(NVIC_DIS0) = 0xffffffff;
HWREG(NVIC_DIS1) = 0xffffffff;
HWREG(NVIC_DIS2) = 0xffffffff;
HWREG(NVIC_DIS3) = 0xffffffff;
HWREG(NVIC_DIS4) = 0xffffffff;

//
// Enable and reset the USB peripheral.
//
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);
ROM_SysCtlPeripheralReset(SYSCTL_PERIPH_USB0);
ROM_SysCtlUSBPLLEnable();

//
// Wait for about a second.
//
ROM_SysCtlDelay(g_ui32SysClockFreq / 3);

//
// Re-enable interrupts at the NVIC level.
//
ROM_IntMasterEnable();

//
// Call the USB boot loader.
//
ROM_UpdateUSB(0);

I saw it, thanks. Unfortunately, for whatever reason, it doesn't work in my application.

This is the only way I can get the SBL to work:
ROM_IntMasterDisable();
ROM_UpdateSSI();

Hope someone else finds this helpful,

B