Application download with external WDT

If you are still at the design stage I would consider trying to prevent the external watchdog pulling the reset when the JTAG is connected. 

How long a pulse is required to kick the watchdog - could you change your GPIO and drive it from one of the JTAG pins so that it will get kicked a lot during programming? 

Alternatively could you add some sort of pullup/pulldown combination - if the external watchdog pulls the reset low with a large resistor but the JTAG (when connected) pulls it high with a much smaller resistor then you could sort of ignore the external device although this is not an ideal solution.

Another option could be just to extend the timeout period to be long enough to ensure programming completes successfully?

Unfortunately, for this specific board we are in production phase and hardware changes are not possible, for our next board we will consider to do it if there won't be any other choice.

The watchdog timeout is set by hardware configuration,  other configuration would mean longer timeout intervals for watchdog to operate and this is not suites our requirements.

Still maximum time for this specific watchdog chip is 24 seconds and the whole process requires more than that.

The sufficient interval to kick the watchdog is a couple of ms but the interval to do it, is every 2 seconds.

The pullup option sounds feasible.

Have you considered programming the main code using some form of bootstrap loader?  You could write a small custom bootloader that will communicate with a PC to download all the firmware whilst regularly kicking the watchdog.  Hopefully this small bootstrap could be programmed into the device over JTAG before the watchdog kills the processor. 

You might actually be able to modify the TI bootstrap to kick your watchdog as this could save a fair amount of development time.

We used an external WDT on out first hardware too. With the same result.

I also wondered how such a design could pass the design phase into production. While programming the software on a prototype, it should have been obvious.

The problem is, that during program upload teh external WDT isn't triggered. Therefor it will trigger a reset. This reset, however, will interrupt the program download (which is actually injecting code into MSP ram that will program teh flash with provided data - a reset will cause havoc here).

The solution was to put a series resistor of 10k between the WDT and the reset pin. On the programmer adaptor, we added a 4,7k resistor pullup. So as long as the programmer was connected, the WDT was unable to pull the pin down below 2*VCC/3. The programmer had no problems pulling the pin down when required to reset the MSP.

If you cannot put a resistor in between, you can try to override the WDT output. By using a strong pullup that is stronger than the WDT output (if it is possible) and then pimping the programmer reset pin so it can fight thsi strong pullup. It's a lousy workaround but might work. It depends on the WDT output specs.

Well, until now we used an IAR which is handling this problem quite well, for the development I took one of the boards and took out the WDT.

Anyway, thanks for the suggestions.

After reviewing suggested options in this forum and  in code composer forum

I decided for now to solve my problem by modifying the MSP430 Flasher command line tool.

Out of interest what is the modification that you made?

Instead of using existing function for programming which does all at once I separated the programming into chunks and between each of them added a command to program the relevant register to "calm down" the WDT.

Of course, it required to some extra coding to parse the TI-TXT file.

smart idea.
The programming of the flash is usually done by injecting code into ram that contaisn the flashing funciton and the data to flash. Then the code executed and when done, the next portion is injected into ram and the funciton is executed again.
It should be possible to add a 'toggle wdt' sequence directly into the flashing loop. But executing custom code between separate programming calls will do the trick as well.
Lucky you, that the WDT timeout is not shorter than the time required for the BSL command transfer and teh erase tiem for a flash segment.

I am using JTAG interface and not the BSL.

RuvMan said:

I am using JTAG interface and not the BSL.