Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Peabody last won the day on March 22 2019

Peabody had the most liked content!

About Peabody

  • Rank
    Advanced Member

Recent Profile Visitors

969 profile views
  1. Thanks very much for your replies. I'll go back and study what you've said, but it kinda looks like it just needs to stay in Naken assembler. That produces a .hex file which I flash to the chip with TI's MSP Flasher. There is no "environment". And I think any attempt to convert it to C is just bound to make it larger and less efficient.
  2. I just posted a Github repo on a 1K SD card bootloader for the G2553 and G2452: https://github.com/gbhug5a/SD-Card-Bootloader-for-MSP430 It's written in assembler, but that's not really accessible to most people who use Energia. So I wondered if it would be possible to rewrite it in C++. But I don't understand much about how C++ does things, and don't know if it's possible to do the same things in the same space, or anywhere near the same space. My code uses all 12 general purpose registers, mainly because operations on registers are smaller instructions than operations on memory locations. Also, I specify in ram the exact location of every bit of ram I use, other than the stack of course. It all fits in 1K, but with exactly four bytes to spare. If I do away with setup() and loop(), and just stick with a main(), is it possible to do stuff like this in Energia? Is it possible to specify exactly where things will be located? Are there any examples of doing this kind of conversion? Well, this may be a bridge too far. But I thought I would ask. I was also thinking that if the C++ code worked in Energia, it could possibly be ported back to the Arduino world.
  3. Thanks. I finally found a tutorial that may help: http://codeandlife.com/2012/04/02/simple-fat-and-sd-tutorial-part-1/ By the way, when I first compiled the example code from the PFatFs library, I got a strange warning that appears to be related to the IDE. Should I report it somewhere? C:\energia-1.8.7E21\hardware\energia\msp430\cores\msp430\atof.c: In function 'atof': C:\energia-1.8.7E21\hardware\energia\msp430\cores\msp430\atof.c:71:9: warning: floating constant exceeds range of 'double' [-Woverflow] Sketch uses 8236 bytes (50%) of program storage space. Maximum is 16384 bytes. Global variables use 344 bytes (67%) of dynamic memory, leaving 168 bytes for local variables. Maximum is 512 bytes.
  4. I've been working on alternatives to updating firmware in the field, and wondered if a good alternative might be to embed a microSD card socket in a project, and use that to update firmware. It would require no cables or interface devices. Just copy the update file to the card, insert it into the slot, and power up the device, which would then detect the card, and use the file contents to flash new firmware, then (possibly) erase the file. I've downloaded the PFatFs.zip library from about 2016: https://forum.43oh.com/applications/core/interface/file/attachment.php?id=9251 Is that the latest version? Anyway, I don't have a feel for how much memory this would use, and perhaps more important, how much RAM is needed. Would something like the G2553 or FR2311 work? For this use, it would only be necessary to initiate the card, open the file and read the data, and optionally delete the file, but there's no need to write data to a file. So perhaps the code size might be a bit less than what the example ino produces. Does anyone here have experience using SD cards with MSP430 parts? Is this idea worth pursuing? Do you think it would be possible to write the file data to flash or FR in real time byte-by-byte, perhaps by bit-banging the SPI? Are there any hardware issues (I assume 3.3V is ok), large current requirements? Thanks for any insights and opinions.
  5. This continues on a new thread I started announcing the new modified BSL-Scripter. https://forum.43oh.com/topic/13429-modified-bsl-scripter-for-windows-now-works-with-ftdi-and-other-usb-to-uart-adapters/ Profound thanks to nagaokanchi for making this possible.
  6. A new WIN32 version of BSL-Scripter.exe has been compiled which allows BSL flashing using generic USB-to-UART adapters such as the FT232, CP2102 and CH430 as the hardware interface. It can be used with MSP430 F5xx F6xx, and FRxx parts with UART BSL. This version has a new MODE line option "INVOKE", which causes Scripter to directly generate the BSL hardware invocation sequence on the adapter's DTR and RTS outputs, which in turn are connected to the /Reset and Test pins on the target device. It produces the pattern shown in Figure 2 of slau319w.pdf and slau550s.pdf, which is normally generated by the Rocket or MSP-FET. If the INVOKE option is used, you must include the PARITY option as well. I have successfully tested the new Scripter on an MSP430FR2311 using all three adapter types. It would be helpful if others could test other relevant MSP430 parts and report the results. This has finally come about as a result of the generous efforts nagaokanchi, also known as "drcrane" on Github, who not only got TI's source code to compile with new versions of all the dependencies, but also navigated the mysteries of BOOST to control the DTR and RTS lines. The new Scripter and a related Instructions file are contained in "BSL-Scripter-v3.4.1.zip" in the Releases folder of his repository, which also contains the source code: https://github.com/drcrane/bslscripter-vs2017/releases For those who must run an official TI version of Scripter, I will leave on my Github the now-deprecated kludge option for using these adapters with the official Scripter, but of course it requires either manual intervention or an additional circuit: https://github.com/gbhug5a/CP2102-with-BSL-Scripter-for-MSP430 And finally, a reminder that the older MSP430 parts which use BSLDEMO2 for flashing, including the F1xx, F2xx, F4xx, and G2xx parts with BSL, can also be flashed with these adapters if a modified version of BSLDEMO is used, such as the "BSLDEMO-2.01C.exe" found in my other repo: https://github.com/gbhug5a/MSP430-BSL Texas Instruments has neither reviewed nor approved any of this. But I continue to hope TI will officially make similar changes to BSL-Scripter and BSLDEMO to support the use of these generic adapters.
  7. I haven't looked at your latest version, but I tested the release build version 2, and it works!!! The 15ms sleeps don't seem to matter. Pics below. So at this point we have several variations open related to sleep times and methods used to change DTR and RTS. I would suggest that you just pick what options seem best to you and let me confirm one last time that they works, and we can publish. 🙂 One issue that comes to mind concerning which choices to make is that if one option might be usable in any future Linux or Mac version, that might be the best one. The other consideration is that the fewer changes to TI's code, the more confidence others will have in the outcome. So, for example, if this latest version leaves TI's original TestReset.h unchanged, that might be best even if it isn't very elegant. I can't thank you enough for jumping into this. I'm very pleased that this BSL option now exists. Edit: I just tested Release V3, and it works too. So let's just go with that one. What do you want to call it? How about BSL-Scripter340B.exe?
  8. Thanks very much. Your Set and Clr work quite well. I've attached a scope picture showing what happens to the DTR and RTS lines. There are two problems: 1. Each sleep is supposd to be 10ms. The first sleep is significantly less than that. It may be necessary to add another 10ms sleep line right after that first one. All the other sleeps are actually about 15ms. I think that results from the default Windows tick time. I think it's likely that the difference won't matter. 2. The big problem is that after the last sleep ends, something is bringing DTR low - equivalent to rst.Set(), or resetting flow control to none, or something similar. I don't know what is causing that, but it has to be fixed because DTR is connected to the /Reset pin, and nothing can be flashed if it goes back low and puts the processor into reset.
  9. I agree that the code I used in my CP2102 repo is not right for this. That was plain C, with no Boost involved. But I don't understand what is wrong with TI's original TestReset.h code for Scripter. It appears they DO use boost:asio to set DTR and RTS, and their code matches other examples I found online. My changes to UartComm.cpp contain my new calls to the TestReset.h functions for switching DTR and RTS. They have no connection to the CP2102 code. What is still puzzling is why TI #included the functions in TestReset.h, but never used them. Perhaps they used them in an older version.
  10. At the risk of making you regret you did this, I need to ask if you can point me to anything that would explain what's going on in TestReset.h. I know nothing about Boost, or really C++, and the code there just doesn't make any sense. I don't see where "initState" comes from. It doesn't appear anywhere else in the source code, the libraries you included, or the Boost download I did. Also, it appears to be circular logic, and writes before it reads - it all seems upside down. But I've found that exact code elsewhere online as a standard way to do serial ports, but unfortunately without explanation. I also don't see how the TestReset.h code ever gets executed. "TESTControl" and "RESETControl" don't appear in any other source file. What I need to do is (1) stop Scripter from automatically bringing DTR and RTS low, and (2) have it instead generate the invoke pattern itself if a new MODE-line option is selected. #2 I have already done in 😄 https://github.com/gbhug5a/CP2102-with-BSL-Scripter-for-MSP430 but I don't know about #1. TestReset.h is the only source file dealing with DTR and RTS, but I can't change it until I understand it, and make sure changing it doesn't mess up other things. Anything you or anyone can do to shed light on that code would be appreciated. Edit: I've done more searching, and have concluded that if TESTControl and RESETControl are not called from anywhere in the source code, then they are not being used. But they could be. By me. It looks like these functions are the normal way to change the state of DTR and RTS. So I should be able to call them with the appropriate argument. Then I would only need to add the 10ms delays between state changes. Also, if I'm generating the invoke sequence, it doesn't matter that the lines are brought low first (#1 above). In any case, if TestRest.h isn't being used to do that, it's probably just the way Boost opens COM ports when FlowControl = None, and there's nothing I can do about it. If that sounds right, then I'm going to concentrate on adding the "INVOKE" option to the MODE line (presumably the same way "PARITY" is done), and adding the invoke sequence. And all I need to understand about TestReset.h is that the functions there work.
  11. Thank you very much for posting this. I really appreciate it. I'm surprised you remembered the original post. I have downloaded the repo ZIP file, and will study it carefully. But I suspect it will still be way over my head. I've never actually used a "real" compiler before. But I will do my best to figure it out. Can you say what you needed to change to get Scripter to work with the MSP432?
  12. OK, so you don't use a timer-based PWM output, but vary the ON time in your code (NOPs or whatever) based on the number of segments being lit. And I assume the "worst case" is displaying an 8. Well that's pretty cool. And assembler is good for this kind of thing. I did all of my version in MSP430 assembler first, then moved it to Energia/Arduino to make it more accessible. What LVC part did you use?
  13. That's very interesting. Do you vary the PWM rate depending on the number of segments being lit up? And no resistors on the common cathodes?
  14. In case it might be of use to someone, I've posted a Youtube video and created a Github repo dealing with an alternate way of multiplexing 7-segment displays that has a greatly reduced parts count. It's multiplexing by segment instead of by digit. The video shows this method implemented with an MSP430G2553. The Github repo has demonstration Arduino Nano sketches, but they should work as-is with Energia except for the pin assignments. The video is on my local OSH group's channel, and I can't respond to comments there, but will answer questions here if there are any. https://www.youtube.com/watch?v=8w09Zy8MQrc https://github.com/gbhug5a/7-Segment-Displays-Multiplex-by-Segment
  15. I just wanted to say that I think I found the answer to the non-regular millis, at least in the Arduino IDE, and I suspect it's the same in Energia. The interrupt that updates millis is actually a bit slower than 1ms. So periodically, the millis value is incremented by 2 so as to keep the average rate at exactly 1ms. Since my IF statement executes every other milli, it will execute after only 1ms when the millis count increments by 2. And that's why the scope showed the irregular trigger.
  • Create New...