TM4C1294 ROM Bootloader

But I thought that's what the autobaud feature was supposed to handle. I've tried all baud rates between 115200 and 9600. None were successful.

As another piece of information, I know my setup works. My firmware has an upgrade command that calls ROM_UpdateUART(), and that works if I disable autobaud support. But of course, the UART is already set up to the proper configuration before the call.

I always believed auto baud rate was from the client perspective not the server in most written IEEE standard.

The server would some how automatically adjust Baudot timing after a few bytes were received back from the client.

Data sheet does concur with supporting 5-25mHz select crystals shown near page 1842.

BTW:

Do you have Boot CFG register 68, reset default GPIO port H pin 7 pulled up to VDD as to enable the ROM boot loader?

May this outside observer - w/little to offer this subject - note that BP indicated that PH_7 must be pulled up - for the ROM boot loader to function!  Such requires NO programming - and if his PH_7 guidance proves valid - you've not (yet) addressed that (quick/dirty) directive!

Scott Kassan said:

All input is welcome

Such describes those (few) parties to which I'm (on occasion) invited.    My "gift/bribe" left just outside, entry door...

Is your choice of PH_0 clearly documented - in your MCU manual - as "proper" for b/l activation/engagement?    I know the other poster (not) to have custom board - his knowledge thus likely confined to vendor's standard issue board.   (not yours)

Should PH_0 prove proper - and you're driving it to spec - my idea bank reads, "empty."    Bon chance...

CB1 to smells a simple mistake at hand - chimes in like a hawk. ;)

Seems an earlier clue missing necessary enable port H pin 7 is indeed the case. There fore LM Flash will never invoke the ROM boot loader when so commanded.

Simple test might include first programming the BootCFG register to use GPIO port H pin 0 via JTAG port then try to use LM Flash once again.

Unlikely a Baudot issue at all, BTW an intelligent client can and does automatically adjust his rate to match the host. The cling word auto adjust on the server side infers the Baudot divisor is adjusted to match the crystal and the default Baud rate always remains at 115200.

Quoting from the data sheet for the device (section 5.2.2.2, page 222):

If the flash address 0x0000.0004 contains an erased word (value 0xFFFF.FFFF) or the EN bit is of the BOOTCFG register is clear, the stack pointer and reset vector pointer are loaded from ROM at address 0x0100.0000 and 0x0100.0004, respectively. The boot loader executes and configures the available boot slave interfaces and waits for an external memory to load its software.

This is the behavior I'm trying to invoke. The GPIO pin only comes into play if the chip has been programmed and 0x0000.0004 does not contain 0xFFFF.FFFF. It will be used as an emergency recovery mechanism in the unfortunate event that an update is interrupted.

The goal is to be able to program brand new boards using the serial port rather than JTAG. If I have to connect JTAG to program the BOOTCFG register, I may as well go ahead and program the whole device while the JTAG is connected.

"The GPIO pin only comes into play if the chip has been programmed and 0x0000.0004 does not contain 0xFFFF.FFFF".

My take is the MPU reads register 68 after a POR, if pin H7 is High the Rom BL is invoked. Other wise RBL would be invoked after IPL when not desired for RBL invoke after POR.

So pin H7 is High && location 0x0000.0004 is !Not 0xffff.ffff, inferring an IPL succeeded. RBL will not be invoked next POR negating the need to install a jumper to pull down pin H7 after IPL, initial program load. You save .50 cents on a jumper and gold plated pins and only add one 10k pull up resistor. Not to bad a trade off!

I'm not using DTE, only RX and TX. But I'm sure the port hardware is capable of working correctly. It works when my code calls ROM_UpdateUART().

It's rather difficult to wire anything to port H7 since the part I'm using only has H0:H3.

My interpretation of the boot logic is as follows:

if location 0x0000.0004 constains 0xFFFF.FFFF

ROM Bootloader // This is the one I'm having trouble invoking

else if BOOTCFG and GPIO in proper configuration

ROM Bootloader

else

Boot from flash

"It's rather difficult to wire anything to port H7 since the part I'm using only has H0:H3."

How is that possible when the TM4C1294NCPDT has over 128 pins?

The PinMux tool will not show GPIO pins of register 68 since it is already programmed by default. Solder a wire to the pin H7 then MPU will invoke the RBL anytime the flash has been erased 0xffff.ffff.

5.2.2015: Don't shoot the messenger for relaying incorrect datasheet information! We often don't have time to go check every aspect such as the TQFP package pin layout. This case it was assumed a custom chip had been made for what ever the reason. Later discovered the datasheet incorrectly claims defaults of register 68 assert pin H7 on a Truncated GPIO port H. Poster did not kindly relay that information.

The LM Flash expects COM1-4 UART connections and windows USB virtual serial device driver iseemingly out of the question without first adding ICDI support via TM4C123 MPU. The TM4C1294 Launch Pad uses embedded code in TM4C123 to access the USB serial CDL driver and relays the serial Com port configuration parameters to the client such as LM Flash Tool.

"I'm not using DTE, only RX and TX." 

Elaborates effectively to communicate the RBL configuration: Score = 3

*Typical to Infer RS232-DB9 pin port of PCAT is DTE configured (data terminal equipment).

Page 1822 TQFP shows some interesting details about RBL and USB. RBL might just support Windows virtual serial CDL driver after all by redirecting UART0 RXD into virtual USB. Then LM Flash may infer selected UART Com1 as the serial USB virtual pipe.

If that is your intent you will have to install the Windows device driver found in { TivaWare_C_Series-2.1.0.12573/windows_drivers/usb_dev_serial.inf}.

Don't believe using the bulk driver for LM Flash since it suggests a serial Com port selection.

Seems the text states we must use a GPIO pin to invoke the RBL:

At reset, the user has the opportunity to direct the core to execute the ROM Boot Loader or the application in Flash memory by using any GPIO signal from Ports A through H as configured by the bits in this register.

"has the opportunity" infers a mandate in order to use RBL virtual CDL pipe into LM Flash on selected COM ports.

Likely is port D7 NMI to invoke the RBL. What say CB1 chime into that NMI thing,

BootCFG sequence :

1. The BOOTCFG register is read. If the EN bit is clear, the ROM Boot Loader is executed.

2. In the ROM Boot Loader, the status of the specified GPIO pin is compared with the specified polarity. If the status matches the specified polarity, the ROM is mapped to address 0x0000.0000 and execution continues out of the ROM Boot Loader.

3. If the EN bit is set or the status doesn't match the specified GPIO port polarity, the data at address 0x0000.0004 is read, and if the data at this address is 0xFFFF.FFFF, the ROM is mapped to address 0x0000.0000 and execution continues out of the ROM Boot Loader.The status would be from SSIO or other retuned status.

KEY:

** At POR the EN bit is cleared by setting it to 1, the reset default and therefore RBL reacts to GPIO pin.

Boot GPIO Enable: EN=1

Clearing this bit enables the use of a GPIO pin to enable the ROM Boot Loader at reset. When this bit is set, the contents of address 0x0000.0004 are checked to see if the Flash memory has been programmed. If the contents are not 0xFFFF.FFFF, the core executes out of Flash memory. If the Flash has not been programmed, the core executes out of ROM

That's good detective work - your (rare for here) update is very much appreciated.

May we ask, "How you've confirmed that the ROM boot-loader was invoked?"     (we note such claim in 2 places - thus this fact should be detailed)

Might you (more positively) confirm that the (system) is correctly detecting your external xtal's value - by switching to a different value xtal - and then noting, "if/how" that's accommodated?

Many would benefit from your success in this effort.     My push for more, "support/verification for your findings" aims to better enlist vendor aid.

Good progress yet mystery has lingering Mary Drew artifacts in the mix.

Earlier asked if your crystal manufacture is listed in acceptable vendor shown in datasheet.
TI must have tested all those listed to be mostly error free to within so many OSCPS.

Amit,
Forgive me. I'm not familiar with the abbreviation WA. Could you please point me to the appropriate document. I tried Googling TM4C1294NCPDT Errata and found this link, but it is non-responsive: www.ti.com/.../getliterature.tsp;.

For the benefit of others, after looking at my schematic, Amit suggested installing the resistor for RBIAS. That proved to be a daunting task, but he also suggested that as a quick-and-dirty test, the pin could be shorted to ground directly. That was a little easier, since an adjacent pin is ground. With assistance from my younger colleague with better eyesight and steadier hands, that test was performed. After going through a reset cycle to completely erase the flash, I was able to successfully program the chip directly through the serial port.

Well deserved is to check the box Question Answered - raise the Flag in Amit's support remedy.