After about an hours browsing TIs website I seem to find out that their debug/initial flash programming interface is secret.
I know there are people familiar with this part here, so here is the question: Is there a known way I can get enough data to be able to adapt my tools to program the MSP430? Has anyone done it? Or perhaps I am just not looking hard enough?
The 430 looks like a good fit for an application I have but if it includes blackmailing me to pay up someone for the right to program the part it is out of question here.
This is for a bootloader running on the chip. Question remains how to program the bootloader in the first place, or to reprogram the bootloader if it gets corrupted.
Sounds like you have been through this quest already, is it a waste of time? Looks so but the chip is nice so I did this extra check, will do another few perhaps.
On a related note, if the 430 loses then the likely winner would be the Freescale HCS08AW. I spent some time browsing and it seems enough of it is documented so one can program it and do something without having to rely on third parties and there are no mandatory magic boxes/software. Have you been through this one (family, that is)? Any experience? Obviously I'll dig into it deep enough before designing it in, but some experience/hints at this stage can save a lot of time and effort.
That looks like it will do the job, thanks. I'll have to look a bit deeper into the instruction set etc. now to see how I'll be debugging the thing - breakpoints and step by step - and if this can be done without secret magic boxes this may be it.
Without the secret magic runes from TI you will not be using the on- chip debugging hardware at all. Breakpoints can be simulated but trace might be quite challenging indeed.
And I was just leaning towards the 430... So apparently the CPU has no single step trace functionality itself - what about some sort of timer capable of doing an NMI after a few cycles so I can do it the good old way, do you know if some family members have that?
Not sure. There's the WDT but I don't know how fast you can get it to fire; probably not fast enough for your requirements.
I'm still a bit baffled why the need to roll your own debugging hardware and software factors into your choice of microcontroller.
Of course any host-side software that uses the interface DLL from TI can single-step code. I BELIEVE the information on how to use that DLL is obtainable, if not public knowledge.
Thanks for the help. I looked a bit deeper and I'll go for it. I looked back at how I have done their 5420 DSP, same story here, probably a bit easier (there I have used no NMI but IRQ, now did I have an NMI then at all I don't remember :-). Anyway, setting thing up to some sort of debugger will cost me a few days which is acceptable. The key factor is the fact that they have a part with 10k RAM, which is plenty for both the code and data while debugging this application, so I'll be fine.
I manage to date to maintain a development/computing environment which is 100% my property. It runs under DPS, which is my property as well, so I have 100% control over 100% of the software I use for development. You won't believe how often how timesaving this can be. If a silicon manufacturer tries to sell me a windows/linux/whatever PC attached to the chip I want, he loses. Another way of putting this may be showing the sheer amount of code I have and do put to work, see
formatting link
:-). Counted are al sources I have written since 1994 or so, I also have older code still at use, its sources are buried deeper, though.
I suppose it is available to party members only, I have some memory trying to get that info on the 5420 in vain - but it was long ago and I am not sure, I may be wrong on this, perhaps it is obtainable under NDA. But I just won't neer it, I'll be fine with what I saw.
As far as I know, only Freescale fully documents their on-chip debugging capabilites in public documents you can download. And these documents are somewhat easy to understand. In the 08 line, only some members have the BDM, so make sure your particular chip has it.
This info for Arm is also available but is far more complicated and you need a lot of supporting knowledge on JTAG to be able to use it. But the vendor-specific access to the EmbeddedICE module via various pins may not be well documented. Accessing the EmbeddedICE module programatically (not via JTAG pins) is also poorly documented, if at all.
TI documents the interface to their Windows debugging DLL if you sign a non-discloseure agreement. There is no money involved and they'll send you a lot of good example code. The DLL is free and re- distributable.
If you need to use linux with the msp430, there is a solution for debugging in the mspgcc package. It's got a closed source proxy, but it's free and you don't need to sign anything if you interface to the proxy.
Well I know they do - for most of their parts. Try to get data on the JTAC accessible internal "COP" (that's what they call the debugging facility, BDM like) on their PPC products, no way getting it even under NDA. Party members only area...
[Luckily the PPC has such extensive debuging features in its general architecture one can live without their "COP" thing quite well - as I do :-) ].
Generally Freescale have had almost all of the processors I have needed over the years, but the MSP430 (one of the 1 series I picked) is just a very very good fit, so I took it. The way I took TIs 5420 DSP several years back...
I am totally uninterested in any chip feature which comes if I buy a wintel or whatever PC attached to the chip. Like I said elsewhere in that thread, I do not need such a PC to do my development work and if getting one involved is the only way to use a part, the part is not designed in. [So far I manage it, although I can see the moment coming when we will be allowed only to select what we want from a dropdown menu like monkeys - but those controlling the menus (and what these menus include...) have some more control to seize before they can enforce this].
Hi, I'm new here. I'm italian and so my english is not very good...pardon!
I have need to program MSP430F2121 (28 pin, 4KB, UART) using BSL (Bootstrap Loader) controlled by PC. By Visual Basic 6, I'm be able to driver RS232 (TX, RX, RTS, and DTR) and I'm be able to communicate to MSP430F2121.
I make thing step-by-step, reading before sall0089d and slaa0096d.
First Step: I send to MSP SYNC (0x80) command, and I receive ACK (0x90). It's all right!
Second Step: After SYNC command, I send MASS ERASE command: HDR: 0x80 CMD: 0x18 L1: 0x04 L2. 0x04 AL: 0x00 AH: 0xFF LL: 0x06 LH: 0xA5 CKL: 0x7D CKH: 0xB9 The parameters AH, AH, LL, LH are suggested by TI (see the example of Visual C++ application for Win32) MSP430 answers me by ACK, 0x90 and in effect all memory is empty, all
0xFF But there's a mistery: if I send RX PASSWORD, MSP430 answers me NAK,
0xA0 after the fourth byte and voltage level goes low by MSP430: WHY???
Thirth Step: After SYNC Command, I send RX PASSOWRD, in other words, I send to MSP430 the password, that is 32 times 0xFF after MASS ERASE. Now MSP430 answers me ACK, 0x90. It's all right! But some times, MSP430 answers me NAK, 0xA0 after the fourth byte and voltage level goes low by MSP430: WHY??? In MSP430F2121, as other new chips, when password is wrong, MSP430 erase all flash memory, filled with 0xFF. When MSP430 answers me by ACK, I verify, reading the flash memory, that RX PASSWORD command is processed right.
Fourth Step: After SYNC command and after RX PASSWORD, I try to write 2 bytes (always even data, because MSP430 is a 16 bit MCU!!) in flash memory, but MSP430 answers me NAK, 0xA0, ALWAYS!!! The string that I sent is: HDR: 0x80 CMD: 0x12 L1: 0x06 L2. 0x06 AL: 0x00 AH: 0xF8 LL: 0x02 LH: 0x00 D1: 0x12 D2: 0x34 CKL: 0x69 CKH: 0x27 Seeing in details: L1=L2 and indicate that the bytes are 6 (AL, AH, LL, LH, D1, D2) AL, AH indicate the start address memory using little-endian notation:
0xF800 LL, LH indicate the number of pure data bytes: only 2, D1 and D2 D1 and D2 indicate the data that I want to write into flash memory CKL, CKH indicate the cheacksum calculated by: CKL=HDR xor L1 xor AL xor LL xor D1 xor 0xFF CKH=CMD xor L2 xor AH xor LH xor D2 xor 0xFF Why I add "xor 0xFF"? Because I must inverted the subtotal xor calculation: CKL=INVERTE (HDR xor L1 xor AL xor LL xor D1). It's the same! But I receive from MSP430, NAK: WHY????
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.