Thanks for the reply, but I'm afraid that I must not have successfully communicated the problem.
On Sat, 2005-01-15 at 21:08, [email protected] wrote: > Message: 5 > Date: Sat, 15 Jan 2005 21:08:13 +0100 > From: Chris Liechti <[email protected]> > To: [email protected] > Subject: Re: [Mspgcc-users] BSL on msp430f1232 question > Reply-To: [email protected] > > Jeff Williams wrote: > > I'm working with an msp430f1232. For the purposes of in-system > > programming I'm trying to use the BSL. I am, however, not having > > i have the BSL working with F1121, 123, 13x, 14x, F449, ... > if you're using the windows installer of mspgcc, you already have it: > msp430-bsl > for other platoforms get it from the mspgcc CVS. module "python" . you > need to have python installed, but you probably have it already if > youre > on linux or *bsd > > there are also some NSIS scripts in the mspgcc CVS which you can use > to > make simple standalone applications for field updates. The msp is buried behind another processor on an embedded board. There is no connection to the outside world and no PC available even if someone was present and had a desire to update the msp's software. Updating of the msp software is to be done via one of the embedded processors. Not that's it's particularly relevant, but since you comment later about issues of capacitance and appear to make several assumptions about what I'm doing, the msp430 -RST and TEST pins are tied to an ASIC that maps those two pins to two bits in the memory space of another processor. They are toggled by a series of memory writes on that processor. I've already tied an oscilloscope to those two pins to verify that they are functioning correctly (as part of my hardware verification). This is further verified by the fact that I DO appear to be able to synchronize with the BSL. From my original message, my first serial transmission works just as advertised in the TI documentation. TX: 0x80 RX: 0x90 > > So, I'm puzzled. I've verified the hardware and everything appears > to be > > correct (I even double-checked the serial stream on an oscilloscope) > so > > I'm leaning toward a software issue but at this point after > following > > TI's ICD I'm just puzzled. > > - are the control lines correctly connected, no unneeded signal > inversion etc.? > > - youre hardware is maybe a bit "slow" i.e. large capacitors, so that > you need to wait a little longer after a reset. > > - your control signals like RST / TEST may need longer pulses beacause > of high capacitance. > > i have seen hardware with the later problem. msp430-bsl aplies RST and > TEST pulses longer than the original from the TI appnotes. it also has > a > --slow option which applies these pulses realy slow... > (it also has options for inverted control lines :-) > > chris As mentioned previously, I DO appear to have correctly activated the BSL, it's just that the BSL, after the synchronization character (that it ACKs), rejects all of my further messages (with the 0xA0 NAK character). From my original message, my two test streams for mass erase are as follows: TX: 0x80 TX: 0x18 TX: 0x04 TX: 0x04 TX: 0x00 TX: 0x00 TX: 0x00 TX: 0x00 TX: 0x7B TX: 0xE3 RX: 0xA0 <== rejected TX: 0x80 TX: 0x18 TX: 0x04 TX: 0x04 TX: 0x00 TX: 0xFF TX: 0x06 TX: 0xA5 TX: 0x7D TX: 0xB9 RX: 0xA0 <== rejected The real question isn't "have I gotten into the BSL". The evidence suggests that I have. The real question is "why did the BSL reject my messages"? An interesting side note is that I hard-coded a message stream in a simple test application and inadvertently changed 1 bit of the checksum: TX: 0x80 TX: 0x18 TX: 0x04 TX: 0x04 TX: 0x00 TX: 0x00 TX: 0x00 TX: 0x00 TX: 0xBB <== flipped a bit TX: 0xE3 RX: 0x90 <== accepted According to the documentation, this should have been an invalid message, but the BSL appears to have accepted it as being correct. If this represents the solution to my messaging problem I'm happy to use it, but WHY did this work? It's hard to modify the OTHER messages to conform to the working one if I don't know why the working one worked. I took a look at the python BSL code. I'm not fluent in python, but it appeared to be an almost straight translation of the TI code in slaa096b with a few things like elf support added in. This, however, may only be my inexperience with python hiding the changes from me. Do you, by any chance, have any serial data captures taken while working on it? Something like that would be most helpful. Thanks for the response! Answers are always appreciated.
