Jump to content

Peabody

Members
  • Content Count

    42
  • Joined

  • Last visited

  • Days Won

    11

Posts posted by Peabody


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

     

    Scripter scope.jpg

    FTDI module - FR2311.jpg

    ScreenCap.jpg


  6. 4 hours ago, nagaokanchi said:

    Seems I need to learn more about boost::asio. Please see the latest release for binaries and changes to the code.

    https://github.com/drcrane/bslscripter-windows/releases/tag/v0.0.3-6024887

    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?

    Scripter Release2.jpg

    ScreenCap - Release2.jpg

    FTDI module - FR2311.jpg


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

     

    Scripter.jpg


  8. 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.


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

     


  10. 7 hours ago, nagaokanchi said:

    Hello, I realize this is an old post but I have recently been required to get the BSL working on an MSP432 device. The BSL-Scripter was easy to compile once Boost was installed. I have uploaded everything required (except Boost) and instructions on what to do on GitHub: https://github.com/drcrane/bslscripter-windows 

    I hope this information is useful.

    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?

     


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

     


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


  13. 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.

     


  14. 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. 


  15. 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.

     

     


  16. 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.


  17. On 12/23/2018 at 6:15 PM, Peabody said:

    This is my first attempt with Energia.  Sorry to ask so many questions.  I need to know what state the G2553 is left in after whatever Energia does to it automatically so I know what I need to do, such as:

    Does it set the top of the stack?

    Does it set the clock to 1 MHz?  8 MHz?

    Does it disable the watchdog function?

    Does it return P2.6 and P2.7 to GPIO use?

    Does it leave all port pins as inputs with PU resistors?

    Does it set up a timer to generate interrupts for millis()?

    Also, where can I find this kind of information?  I didn't have any luck searching for it here, or on the .nu site.

    Thanks

    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.


  18. Aside from the interrupt on change issue, I haven't found any way to set up a timer interrupt in Energia other than fiddling with the registers.  But as it turned out, all I had to do was put the entire loop() code in an IF statement that tests whether the required number of millis had passed.  So basically it just does that test over and over, but only executes the code every 2ms.  In assembler, I put the processor to sleep between interrupts, but haven't found a way to do that in Energia.  Anyway, I've finished porting the assembler code into an Energia .ino, and it works fine.  The hex file is about twice as large as the assembler version, which is actually less than I expected.

     

     


  19. This is my first attempt with Energia.  Sorry to ask so many questions.  I need to know what state the G2553 is left in after whatever Energia does to it automatically so I know what I need to do, such as:

    Does it set the top of the stack?

    Does it set the clock to 1 MHz?  8 MHz?

    Does it disable the watchdog function?

    Does it return P2.6 and P2.7 to GPIO use?

    Does it leave all port pins as inputs with PU resistors?

    Does it set up a timer to generate interrupts for millis()?

    Also, where can I find this kind of information?  I didn't have any luck searching for it here, or on the .nu site.

    Thanks

     


  20. 1 hour ago, Fmilburn said:

    Hmmm... that code looks familiar. Energia implements an interrupt with change, probably by the method that jsolarski suggests above.  I don’t use Energia much anymore but it is open source so you can have a look at that if you are interested. 

    I wouldn't know how to find it.  In any case, your code compiled ok, and ran ok, with the on CHANGE interrupt?  Well, it's a mystery.

×