On 2008-01-17, Chris Liechti <[email protected]> wrote:
> hm. when i added the F2xx support it seems that the mspgcc backed got
> unstable in some rare conditions. but it's difficult to debug that.
Unfortunately, the backend that uses the TI library doesn't
support the 2330.
> the JTAG code is mostly based on the slau149 app note with
> some additional code that is able to download a code snipped
> into the RAM and execute it. That is tricky on some parts that
> have a bug in the JTAG logic (so the code i refer works around
> that bug and originally comes wfrom TI).
>
>> Can anybody recommend a simple way to get a hex file programmed
>> into an F2330?
The software from elprotronic is working great, but that means
I have to have a second PC.
> as you have problems, it seems that the F23xx are different to other
> F2xx family members?
Could be. It's a normal 4-wire JTAG port according to the
docs. msp430-jtag with the mspgcc backend never has any
problems recognizing or talking to the part.
> well, the spy-bi-wire parts are a bit tricky. spy-bi-wire uses
> pulse width to encode the data on the TEST pin. now a short
> pulse in the range of 15..100us is sued to select parallel
> JTAG mode (instead to spy-bi-wire mode) which is hard to
> generate from a PC using a "normal" OS like Windoze or Linux
> (without writing low level drivers).
The 2330 isn't spy-bi-wire, so I don't think that's the
problem.
> now the mspgcc backend tries to generate that short pulse that
> is required to enter the parallel JTAG mode. generating this
> small pulse is more by luck than anything else. (fell free to
> review the code in CVS/jtag/msp430/JTAGfunc.c::GetDevice
> (around line 140). and there was a achneg in
> CVS/jtag/hardware_access/HIL.c that does not add delays for
> the special parameters used in the GetDevice code snippet)
It never has any problem entering JTAG mode. The problem is
that after the program operation completes, there are almost
always a few bits that didn't get programmed -- they're 1's
when they should be 0's.
I can run msp430-jtag --upload all day long and it'll work
every time. Same with a program operation, the program
operation itself always succeeds.
The problem is that the verify fails: a couple bits (random
locations as far as I can tell) just don't get programmed from
1->0.
I've tried varying Vdd from 2.5 up to 5V -- no difference.
> so problems can increase if you have high CPU load or if the
> parallel port is slow (try EPP/ECP modes)
>
> one secure workaround is using the USB programmers, they can
> generate the short pulses accurately (thus using the TI/3rd
> party backend) (msp430-jtag needs a patch to select the right
> mode there, so the public version won't work yet for parallel
> JTAG on spy-bi-wire devices). but using the spy-bi-wire mode
> should do.
>
> if someone can contribute a reliable way to generate <100us
> pulses using the parallel port, fell free to speak up ;-)
>
> as last resort, all MSP430 flash devices have the serial BSL.
We never had any problems programming other MSP430 types via
JTAG in the past, and this board was extremely short on space,
so I didn't allocate header pins for BSL RX/TX.
> where i work we use mspgcc and IAR, for IAR we use the command
> line tools (as we want to automate and insert checksums and
> such) and do the download as described above. thus downloading
> a .a43 from any source/tool chain should work.
Thanks, I'll keep the binary-only project option in mind.
Right now the elprotronics SW is working fine.
--
Grant Edwards grante Yow! What GOOD is a
at CARDBOARD suitcase ANYWAY?
visi.com
