TM4C123G Launchpad - Providing a means for software updates

Hello Marshall

Marshall Folkman said:

I have been using the TM4C123G Launchpad for a commercial application for over a year.

I hope you are aware that TI does not recommend LaunchPad and EVM for commercial applications and that there is no legal obligation in case of loss/harm

Thank you amit. I am aware actually, but by the time I found that out I was already knee deep with no time or resources to change. Also, it is just running an agricultural sprayer system so saftey is not an issue and we have had no problems with it out in the field. I probably will change to a new platform soon, but for now I have bigger fish to fry.

If I do need to switch processors to allow for simple software updates at least it would be hitting two birds with one stone, but from my experience switching processors is no small task.

Any suggestions for the problem at hand?

Hello Marshall

1. What kind of connectivity to the micro exists in terms of peripherals that can be accessed without opening the control box?
2. Does it have a Flash based boot loader?
3. Does it have the BOOTCFG register programmed to force it into ROM boot loader and reset/power cycling ability available?

Amit,

1. Good question. The MCU is controlling a couple of pumps (PWM to line driver), a solenoid valve (Output GPIO to line driver), an HMI controller (UART to RS232 driver), and bunch of sensors and switches all monitored via Input GPIO connected to voltage follower buffers (Op amps). Every peice of equipment that the MCU controls or senses can be disconnected from the main controller itself with one possible exception of the HMI controller. The main controller gets it power from the HMI controller. so as long as I can provide an independent 5VDC power sorce for the Launchpad for the software update, then I can essentially disconnect every peice of appuratus from outside of the main controller. Then my only concern would be how would this effect the other circuit components residing on the PCB and of course the launchpad itself. I know for sure that the line driver and the RS232 driver IC's will be fine regardless of how the MCU behaves during the software update. I am pretty sure that the op amps would be fine as long as the external switches and sensors are disconnected from outside of the box. I am a little worried about the 5v buck regulator powering the board though. during normal operation the controller recieves 12VDC from the HMI and the controller uses the 5V buck converter IC to power the launchpad, other on-board IC's, and some sensors.

2. I have no idea what your talking about.
3. I have no idea what your talking about.

Sorry amit. I am a rookie. what can I say. :)

Hello Marshall

Regarding #2 and #3 you would need to contact the developer of the system, who must have written the firmware. Without that information, there is nothing much I can suggest.

Amit,

Sorry for the delay. Through further research I now have a much better understanding of what your talking about, but I still don't know exactly the direct answers to your last two questions. I am using the TivaWare Library for all pheripheral configurations. I use CCSv6 to program/re-program the launchpad. To do this I pull the launchpad off of my PCB headers, connect the launchpad to my PC via the usb<-->micro USB programming cable (UART0) supplied with the launchpad module, and then I run the desired program into debug mode. This naturally re-programs the updated software onto the launchpad board. This should indirectly answer your #2 & #3 questions. I want the customer/sales rep to able to do this using TI's LM flash programming tool and without the opening the control box.

thanks,

Marshall

A few notes

First in addition to Amit's note on TI selling the board as an evaluation board only, you should note that means there are no certifications for it.

Next, 12V supply agricultural sprayer. So this board is in a dusty, wet, corrosive, electrically noisy environment subject to a lot of vibration and temperature extremes. It'll be subject to low voltage and load dump. To that you are adding your own noise sources. Rough environment for a board built for the lab.

As far as updating I have a couple of thoughts. First, especially given the environment, consider going the old route. Don't try to perform a field update. Keep a handful of service spares and swap them in while you update in more pristine conditions. Given this will take place away from the high pressure to get it running again right now such an approach may actually be more effective than trying to perform a software update in the field. You will need to be able to do this if an update accidentally bricks a unit in any case so it makes a good first step.

Second thought, you have an accessible RS232 port. You could use that for the boot load. Use a sequence the HMI won't emit to enter boot mode, perhaps starting with a break. Create a programming cable that hooks into the HMI on one side for power and routes the serial lines to a PC (a three headed cable, PC and unit for serial, HMI and unit for power. You still have to write the bootloader.

Robert

Another thought.

You need a way of validating the binary you download, first that it's not corrupted, second that it is for this target.

In the latter case since at some point you are likely to have multiple products or variations and the binaries are not going to be compatible with the h/ w although they might run and even do damage. Ultimately if you want to prevent counterfeits loading in this fashion it becomes a cryptographic hash.

Robert

Hello Robert

Robert Adsett72 said:

Second thought, you have an accessible RS232 port. You could use that for the boot load.

I am also trying to ascertain the same.

The OP does state that they have a serial port hooked up to the HMI and that it has a connector. That is sufficient for me to think it's available.

Robert

Marshall Folkman said:

The project is starting to take off.

As you've been (commercially active) "for over a year" - wouldn't these (many) issues have surfaced far sooner?  

Direction - offered by (others) here - really does depend upon an accurate description of where you (really) are now.   (i.e. "starting to take off" seems (somewhat) over-stated...and is far too vague to be useful...)

Hello Robert

Marshall said:

Every peice of equipment that the MCU controls or senses can be disconnected from the main controller itself with one possible exception of the HMI controller.

Access may not be that simple.

That was needed for power as I understand. As such a cable adapter can deal with it nicely and fairly easily.

If the HMI needs to be active during an update it's a whole other layer of complexity.

Robert

Robert,

The HMI does NOT need to be active for the update. The only reason I said that is just encase the processor needed to be sourced with power from an independent source during the update. Also, the HMI is not actually running through a RS232 connector. I use a DIN rail external of the control box so really I can connect, disconnect, or re-route any single wired connection going in and out of the box to perform the update. Also, I can mill out a new hole to install a USB panel mount connector if I need to. Earlier I was referring to the RS232 IC chip on the PCB inside of the control box (And inside of the HMI for that matter). The RS232 IC chip does have an extra line available that is not in use. I can update my PCB to route that to any pins of the processor for UART, I2C, SSI, or whatever if desired.

Amit,

I just found your application note; SPMA074. Let me read it and hopefully we can have a more educated conversation about this topic.

Marshall

Hello Robert

We don't know that yet and it is built on a LaunchPad makes it even less flexible when a complex system, has to be put in place.

Hello Marshall

If possible can you share the anit-noise and protection circuit details as there may be other users who may benefit with a jump start.

I really do not consider myself an expert in electronics yet (hence why I prefer to use the launchpad in the first place), but for protecting the processor/launchpad I can break it down into 3 things:

1. Treat the launchpad like any other sensitive IC chip on your PCB and be sure to put in ceramic bypass capacitors between the VBUS (5V) pin and the ground pin on the J3 pin column. The launchpad already has bypass capacitors on the board, but for my application I don't feel it is enough so I installed a 1uF and a 0.1uF ceramic capacitors as close as possible across VBUS and GND. Also the capacitors I chose are rated for larger levels of power.

2. For my application I have two motor drives on the same PCB driving inductive loads as well as a very unpredictable power supply in terms of voltage spikes. For these reasons I have to aggressively prepare for noise. I have two 330uF electrolytic capacitors installed across incoming power (12VDC) and two more 330uF electrolytic capacitors installed across the output power of my 5VDC Buck regulator (which supplies power to the launchpad and other IC's). This is very important!

NOTE: It is important to note that noise comes in different frequencies and harmonics. This is why #1 is necessary even after implementing #2. 

3. Protection of processor pins. I do believe that the TM4C12X processors have protection circuitry for each pin built into the processors themselves, but through using the TM4C123G launchpad in school I learned the hard way that it is not near adequate enough. I know that there are zener diode techniques for directly protecting each pin, but in my application I just make sure to choose IC's that interface directly with the launchpad pins to already have this kind of protection built into the IC itself. Also, I make sure that I follow with exactness all recommendations within the datasheets of these IC's (especially when they talk about bypass capacitors).

Again I just want to note that these things may depend on the application and that I am not that experienced of an engineer. However, my company does have over 50 of these systems out in the field (some of which for over a year) and we haven't seen any reported issues as of yet. Any suggestions will be appreciated.

Thank you.

Marshall

Marshall Folkman said:

I have two 330uF electrolytic capacitors installed across incoming power (12VDC) and two more 330uF electrolytic capacitors installed across the output power of my 5VDC Buck regulator (which supplies power to the launchpad and other IC's). This is very important!

Considering the environment there should also be overvoltage protection and reverse voltage protection. Probably also chokes to reduce the conducted high frequency.

Marshall Folkman said:

I know that there are zener diode techniques for directly protecting each pin

Or series diode pairs to the power rails. Both, of course with current limiting resistors before the zener or diode pair.

Nyquist filters on A/D inputs to eliminate aliasing and provide local charge buffering (aka freewheel caps)

Also take a look at EMI/EMC techniques to route high frequencies away from your board.

Finally read the errata, the 123 in particular has one related to the input pins which requires additional caps on each input. I suspect you can't really get them close enough on the Launchpad to be completely effective. And the EE is effectively unusable for applications that require update and random times during operation.

Robert

Robert,

Thanks for the advice! I will try to implement these things.

Marshall