Jump to content
Forum sending old emails Read more... ×

Peabody

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    11

Peabody last won the day on March 22

Peabody had the most liked content!

About Peabody

  • Rank
    Advanced Member

Recent Profile Visitors

627 profile views
  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. Peabody

    Multiplexing 7-segment displays by segment

    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?
  9. Peabody

    Multiplexing 7-segment displays by segment

    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?
  10. 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
  11. Peabody

    Millis not regular on oscilloscope

    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.
  12. Peabody

    Places we buy things...

    I'm in the US, and I've generally had good results with Banggood. Their products are pretty much the same as you would find on Ebay, but they appear to care about customer service, at least in my experience. The biggest issue for me has been shipping. On two occasions I've paid a higher price to get something from the US warehouse, thinking that shipping would be much faster. But that hasn't worked. The last time I ordered, the items from China arrived before the US items, which took 18 days via DHL. I've become a real non-fan of US domestic DHL. They are much slower than anyone else. I mean, 18 days. There's no excuse for that. I don't know what shipping and customs problems you will have in Canada. Maybe someone else can advise you on that. But with regard to the products, I would generally feel comfortable with Banggood. Of course it depends on how much you're going to spend.
  13. I've written a 7-segment refresh routine that runs every 2 millis at the beginning of loop(). It starts this way: void loop() { CURmillis = millis(); if ((CURmillis - PREVmillis) > 1) { // 2ms refresh period = 71 Hz per segment digitalWrite(18,HIGH); PREVmillis = CURmillis; // Turn the current segment OFF while making changes - prevents ghosting digitalWrite(SEGARRAY[SEGCOUNT], SEGOFF); The digitalWrite to pin 18 has been added so I can measure how long the refresh routine takes to run. Pin 18 is turned off as the last instruction in loop(). So the idea is to put my scope on pin 18, and see how much time the routine takes to run, and make sure there's no chance of an overrun. The good news is that the routine runs in about 25 uSec, so it will never overrun the next milli. But the bad news is that the scope shows that millis do not occur regularly. Pin 18 generally triggers the scope at 2 ms intervals, but there are occasional triggers at other points. I can't tell if the extra triggers are early or late, but they never go away. When I did this test on the assembler version of this code, with the Watchdog timer in interval mode, and the clock running at 1 MHz, the pin 18 triggers are absolutely regular. So Energia is doing something in the background that's causing this behavior. Of course it has to execute whatever is done to update the millis value, but I can't iimagine that this would take much time. But I guess there could be some "beat" in the interaction of the background millis interrupt and the loop() execution frequency. Is there any way to get rid of this millis flutter? Is it possible to hook into the interrupt that Energia uses for millis? If so, I could put my routine into the ISR, and loop() would be empty.
  14. Peabody

    Converting MPS430 assembler code to Energia

    I have everything done that I need at this point. As the original post described, the assembler code did everything inside the interrupt service routine. I was looking for a way to do that in Energia, but using millis and the IF statement accomplishes the same thing. The only difference is that in assembler I was able to turn the processor off between interrupts, which saves some power, but probably not all that much since the oscillator is still running.
  15. Peabody

    How does Energia intialize a G2553?

    What I've found is that it turns off Watchdog, sets the stack pointer to the top of ram, sets the clock to 16 MHz, and restores P2.6 and P2.7 to GPIO use if there's no crystal on those pins. Couldn't find anything else on the ports beyond their normal boot state. Also couldn't find the timer thing, but it must set that up to be able to do millis.
×