Strategy

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Tim Pender
SJTAG Member
Posts: 19
Joined: Wed Mar 12, 2008 9:21 pm
Location: Eastman Kodak, Rochester, NY

Strategy

Post by Tim Pender » Mon Mar 17, 2008 4:38 pm

Strategy
Updates should make the product better not worse, saving last known good version before overwriting is good practice.

For Flash updates, do as much as you can functionally, but allow a backdoor via JTAG to program boot code if possible.

What if there is a problem with an I2c eeprom that is used to boot a processor or DSP? Possibly boot from network then use i2c interface to reprogram the prom. Trying to program serial device via Jtag would require a couple thousand shifts to toggle a serial data bit. What I am wondering is should the ideal gateway chip also include other interfaces such as I2C. This way there would be an alternative master.
Maybe even the Ideal gateway device would support various primary data paths , one would be the Primary JTAG Bus. a second one could be a high speed two wire bus. This approach adapts its self closely to interface with a USB type controller.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 415
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: Strategy

Post by Ian McIntosh » Mon Mar 17, 2008 10:24 pm

Tim Pender wrote:Updates should make the product better not worse, saving last known good version before overwriting is good practice.
Probably, but isn't this implying that you're updating something that you don't fully understand? I mean, if you've got good QA then you should know that the update is going to be an improvement and if you've got good Config Control then you should know what's already loaded.
Tim Pender wrote:For Flash updates, do as much as you can functionally, but allow a backdoor via JTAG to program boot code if possible.
There are several methods now for dealing with large flash devices, but I agree that a JTAG mechanism as a fall-back is almost essential (or at least some mechanism that doesn't depend on the target being able to boot).

User avatar
Tim Pender
SJTAG Member
Posts: 19
Joined: Wed Mar 12, 2008 9:21 pm
Location: Eastman Kodak, Rochester, NY

Re: Strategy

Post by Tim Pender » Tue Mar 18, 2008 2:16 am

roll back configuration
A configuration prom with multiple pages of memory or an embedded flash with a second partition will allow for updates with a contingency plan if the update fails. If for some reason an upgrade fails, the upgrade didn't overwrite the last configuration because it was written in a secondary memory location.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 415
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Post by Ian McIntosh » Tue Mar 18, 2008 8:10 am

We've done something slightly different: We have a large flash that provides the config for several FPGAs. If the board doesn't boot within a given time (e.g. corrupt or blank flash) then the board is re-booted with minimal config data from a smaller backup SPROM that gives just enough functionality to allow a re-program.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Post by Bradford Van Treuren » Tue Mar 18, 2008 2:59 pm

In the telecommunications industry with its view on fault tollerance, there is a design pattern (the exact name slips my mind right now) which talks about rolling the system back to the last known good state as part of the recovery process. To support the fault tollerance requirements, there are many parts of the system that have redundant facilities that are switched to in the event there is a failure. The particular design pattern I am referring to describes the case when the software fails. This can be due to a bug in the current software, a bug in a new release software which adds features, a failed update of new software, or a hardware problem prohibiting access to the software image. In all these cases, there is a reliance on a golden image that will allow the system to perform its minimal function in a state that is known to be good. Thus, if an update fails, there is already a alternate version that may be used to bring the system back on-line while there is a rectification of the problem with the updated image.

I think the strategy Ian is referring to works, but at the cost of downtime to the customer. In avionics, that may be allowed since the update is taking place in a hangar and not airborn. This may not be true for mission data updates, but then again, there is no thought of a previous mission to rely on as a backup.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 415
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Post by Ian McIntosh » Tue Mar 18, 2008 4:02 pm

Bradford Van Treuren wrote:I think the strategy Ian is referring to works, but at the cost of downtime to the customer. In avionics, that may be allowed since the update is taking place in a hangar and not airborn. This may not be true for mission data updates, but then again, there is no thought of a previous mission to rely on as a backup.
Yes, if all or part of a system fails to boot then (except in exceptional circumstances) that system simply won't be flown, so we're only looking at problems that occur during an update and therefore in a controlled environment. As you point out, Mission Data is specific to an individual mission so the concept of a backup for that is largely meaningless.

Post Reply