On 2008-01-17, Chris Liechti <[email protected]> wrote:
> Grant Edwards schrieb:
>> On 2008-01-17, Chris Liechti <[email protected]> wrote:
>>
>> 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.
>
> oh, so this sounds more like a misconfiguration of the flash
> controller frequency.
>
> msp430-jtag tries to adjust the DCO clk. and the code that is
> run from RAM uses the MSP430 itself to programm flash using
> the so adjusted clock.
>
> when the clock adjustment fails is the backend logging a
> warning and tries to continue. you should see this warning
> with "-D" you should see it adjusting the clock too.
I'll try the -D option and see if there are any warnings. If I
could just get msp430-jtag to program parts reliably, I'd be
pretty happy. I could say I'd stop whinging about lack of gdb
support, but that would probably be a lie.
> - advertisement - the same clock adjusting code can be used to
> generate calibration values, see the "msp430-dco" tool :-)
I might give that a try also -- it would be useful to have a
good set of initial DCO settings to minize the time it takes my
DCO code to get to the right frequency.
> i've not checked the 2330 data sheet yet. is there something
> different in the DCO,
AFAICT, the DCO works the same. I use a software FLL scheme to
lock the DCO at 16X ACLK, and the code that does that is
identical to what I used on the 'F149. I have measured SCLK
and verified that it's at the frequency I want, so I know the
DCO adjust routine is working.
> cycle count of some basic instructions (that the code snippet
> run to determine the speed counts differently) or the flash
> controller specs?
I've never looked at the at the flash controller specs. My
applications generally can't burn flash because they're running
at 1.9V.
> wrong flash timing leads to poorly programmed devices, so this
> would explain the effects you see.
>
>> 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.
>
> so erase seems to work, but not the writes.
AFAICT, erase always works. I did an upload after an erase and
it was fine. I never get any errors during the program
operation (like you get when you try to do a program without an
erase). The only error I see is verify failure.
--
Grant Edwards grante Yow! PUNK ROCK!! DISCO
at DUCK!! BIRTH CONTROL!!
visi.com
