• Content count

  • Joined

  • Last visited

  • Days Won


Peabody last won the day on October 31

Peabody had the most liked content!

About Peabody

  • Rank
    Noob Class

Recent Profile Visitors

246 profile views
  1. Last summer I worked on the idea of embedding a USB-to-Serial adapter in Value Line projects so firmware revisions could be done with only a USB cable and the right software, without needing a Launchpad. The adapter chips and modules containing them are now so inexpensive that this makes sense. On the chance that it might be useful to someone, I've written it all up and posted it to Github: The project is summarized in the README, and explained in detail, with needed software and hardware, in the PDF.
  2. Greeeg, I think that chip has a BSL built in. I'm curious whether you considered using that. Of course the built in BSL would need a PC master (the Scripter program?) to drive it, and I understand your bootloader only needs an SD card plugged in. But the built in version has the big advantage of having everything already done for you. Anyway, your version looks very interesting.
  3. I finally figured it out. The special signalling pattern didn't work because DTR is inverted coming out of BSLDEMO2. So that was never going to work. But entering BSL cold start from an application gave errors because I used the +u switch in the command line. It looked like that was the correct thing to do since I was indeed bypassing the signalling pattern, but for reasons I don't understand, when you use that switch the program doesn't send the password on all commands, in particular the ones I was trying to test with (read and verify). But of course the G2553 was expecting a password for these commands, so I got an error. I've recompiled BSLDEMO2.exe from the source code provided by TI, but with the polarity of DTR reversed. So it should all work now. I've asked TI to publish a new version of BSLDEMO2 with DTR polarity the right way for use with the USB-to-serial adapters, but I doubt they will do that. This is all "deprecated", so I doubt they will be willing to spend any effort or money fixing it.
  4. I have a G2553 set up on a breadboard, and am using a USB-to-UART adapter for BSL flashing. TI provides BSLDEMO2.exe on the Windows side to do the flashing, but I've been unable to get it to work. If I use the special signalling pattern on /RST and Test, I get a "synchromization failed" error, and if I boot directly into the cold start vector of BSL, I get a "communications error". So I just wondered if anyone here has actually done this successfully? The two ends talk to each other, but it always errors out.
  5. Hmmm. Your reply seemed much longer when I first read it. I'm just a participant in the project. It was designed and built by someone else. But despite its shortcomings, the 2231 is more than adequate for what needs to be done. It is also extremely low power. I can't really go into the details of the project because it's not mine. As for writing in assembler, the project builder made that choice, but that was fine with me because I never really got comfortable with C, and was already very familiar with assembler for 6502, x86, and even a little ARM. So instead of hundred of megabytes of CCS or IAR, I just use the Naken assembler, which is very small, and compiles instantaneously.
  6. Yes, thanks very much. As I replied to you there, it appears from one of the links you provided that there already exists software that can be used to flash firmware using a USB-to-UART board like the one I have. It appears to be called MSPFET.EXE, but so far I haven't found a good link to it. Still working on that. It appears it would be necessary to change to a 2553 though since the 2231 has no BSL. But that's ok.
  7. I'm new here, and haven't been able to go through all of this thread, but just wanted to report that it's possible to generate the 8 MHz settings for a G2231 without installing a crystal. Steve Gibson did this for a project a while back, and he incorporates the calibration code into the firmware. On powerup he checks to see if the 8 MHz values are there, and if not he does the calibration and writes the result to INFO memory. It takes about 20 seconds to do this, but only on the first powerup. It's basically the same as using a crystal, but instead he uses the low-frequency oscillator in the chip. Of course it's not accurate like a crystal would be, but apparently is very stable. So basically, you set the clock to the calibrated 1 MHz, and using TimerA you count count up for a few low-frequency cycles, then set the clock to trial 8 MHz settings, set the TimerA divisor to 8, and see if you get the same result as before. If not, you adjust the trial settings until you get "very close". This produces an 8 Mhz clock that's as accurate as the 1 MHz calibration is - no better, no worse - which is normally good enough. And I was encouraged to find that if you run this code multiple times on the same chip, you get the same answer each time. I haven't tried it, but I assume with a little tweaking it would be possible to do 12 MHz and 16 MHz as well. I apologize if this has been covered before. I just didn't see anything that didn't require a crystal.
  8. I'm new here, so hello everyone. I'm participating with a number of other people in a project that uses the G2231, and it's necessary to flash new firmware periodically. So, everybody had to buy a Launchpad. But last week I built a cheap oscilloscope kit that uses an STM microcontroller, and was reminded that for such controllers the only hardware you need to flash firmware is one of those little USB-to-UART boards that use the CP2102 chip or something similar. The one I ordered for my scope kit is 3/4 inch by 5/8 inch, comes with the right-angle male header, and the whole thing, micro-USB connector and all, cost $1.62 delivered from China. For future versions of the current project, and for just in general, I'd like to find a way to incorporate one of those interface boards into the project itself instead of every participant having to buy a Launchpad. So the user would just connect the device directly to his computer via USB, and flash new firmware. This would be used only for flashing, not debugging or anything else. I've read through all the relevant threads in this section, and while there was one early thread talking about doing exactly what I want to do, I didn't find any reports of anyone actually doing it successfully. So I'd like to find out whether it's even possible, and if so, what it would take to implement. So first off, while the G2553 datasheet discusses the BSL, the G2231 datasheet does not. So I'm assuming it doesn't have BSL. That would mean only 2-wire JTAG could be used to flash the G2231, which I just assume is completely incompatible with regular serial. I had hoped it would be possible to use the TI command line flasher, but with the CP2102 USB driver, to flash, but that doesn't look feasible. (Although - the interface board I ordered does also have a DTR output that perhaps could be manipulated to provide a clock.) Anyway, while I would much prefer to find something that works with the 2231, it would certainly be feasible to switch to the 2553 if BSL is the only way to make this work. I should also say that if new Windows software is required in place of the command line flasher, that would not be an insurmountable obstacle. I'm not a trained EE, really just a hobbyist. I program the MSP430s in assembler using Mike Kohn's Naken Assembler, and flash with the command line flasher. So all pretty much basic entry-level stuff. But I assume there are lots of real experts here, and would appreciate hearing any thoughts anyone has about how this idea might be implemented. I think it would be a very neat thing to have available for everyone. Thanks very much.