Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JRDavisUF

  1. It was showing up in Energia, just not in CCSv9...but for some reason its there now (pic below is what I was talking about). Coincidentally, wth the TivaC board added to fix the dslite problem and the msp432e appearing, the TivaC board doesn't show up...Should that one be listed to? It's just a little unclear as to whether or not all of the boards supported in Energia are supported in CCSv9. I know in the past there were some compatibility issues, I just wasn't sure if those issues still persisted. Regardless, the MSP432E board appears now, so i'm ok now.
  2. I'm trying to get Energia21 working with my MSP432E (which I'm still struggling with) and ran into a problem. The platform.txt file references dslite However, to get this version of dslite, I must install the TivaC board...which installs this version of dslite in .../Energia15/packages/energia/tools/dslite. It seems like there is a mismatch between the dslite version that the v5.19.0 msp432e board is installing and the platform.txt file jrd PS FWIW, now that I fixed this, I get a "Frequency out of range error"...I tried other versions of dslite (,, and to no avail.
  3. Done. https://github.com/energia/msp432e-core/issues/6 I do see where you can create a new MSP432E CCS project in Code Composer 9, but it doesn't appear to be possible to create a MSP432E Energia Project yet...Is that correct?
  4. I'm using CCSv8 and Energia on a Win10 machine. In my energia code, I have a bunch of setup/loop routines (setupA/loopA, setupB/loopB, etc.) routines as separate files . I'd like to be able to use CPP (#define/#ifdef/etc.) to control whether certain setup/loop tasks are included in the build by essentially making the content of an individual file empty. If I build the code with a certain setup/loop included and then try to use CPP to exclude it, the compiler is still looking for the one I have now excluded and fails the compilation process. I understand that because the setup/loops were in the previous build, that the setup/loop I have now excluded is still included in the build process somewhere, however, I cannot figure out how to get CCS to re-parse all of the files and recognize that this setup/loop is no longer needed. I thought the "rebuild" or "clean" options would do this, but they don't. I am using the Debug build and I can delete that whole directory and it's still looking for the excluded setup/loop. I tried creating an empty .ino file and that seems ok, so I know empty files don't actually require setup/loops within them. None of the files within the CCS GUI seem to mention the excluded file. If I add a new setup/loop, CCS finds it just fine, it's just the removal of them that seems problematic. As a work around, I can create a new project and then copy all of the needed files (not the excluded one) over to it, but this is a bit of a pain and seems like overkill. Does anyone know how to get CCS to update the list of needed setup/loops in the build process for an existing project? thx, jrd
  5. JRDavisUF

    Problems with Serial using interrupts

    Just curious, are you trying to do the Serial.print inside the interrupt? Somewhere in the documentation it says you shouldn't do that. What I do, is use and "Event" variable to trigger something time consuming (e.g., Serial writes) outside of the ISR. So something like this: #include "Event.h" Event SampleTaken; volatile (datatype) SampleValue; setup: setup/start timer SampleTaken.begin(); loop: SampleTaken.waitFor(); print SampleValue; ISR: Grab SampleValue; SampleTaken.send(); jrd
  6. JRDavisUF

    Using 2 UARTS module at same time on msp432

    yes, this approach has worked with my MSP432 Launchpad as well. So example code running at 38400 baud for each would be: Serial.begin(38400); Serial.println("Serial UART"); Serial1.begin(38400); Serial1.println("Serial1 UART"); On the MSP432 Launchpad: Serial RX/TX can be connected using the pins connected to the RXD<<, TXD>> jumpers (with the jumpers removed). Serial1 RX/TX can be connected using Pin3 (P3.2), Pin 4 (P3.3) per the pin map that comes with the MSP432. jrd
  7. JRDavisUF


    I notice in the online documentation for SPI.transfer (https://energia.nu/guide/libraries/spi/spi_transfer/) that 3 prototypes are provided, however in the actual source for my msp432, there are 4 (per SPI.h): uint8_t transfer(uint8_t); uint8_t transfer(uint8_t, uint8_t); uint8_t transfer(uint8_t, uint8_t, uint8_t); uint8_t *transfer(uint8_t *, size_t); <===================== Missing in online docs The missing one is the multi-byte transfer. Arduino documents a similar function in their docs so I assume it's one that is meant to exist (please don't get rid of it ). The main reason I mention it is that because there is another two argument prototype. So it's a bit confusing when trying to debug if one gets errors related to the first prototype (due to a forgotten &), when I was trying to use the second. Also, but perhaps I missed it, I don't see any reference to SPI1 in the documentation. Related to this, are there any plans to provide easy access to the other SPIs? jrd
  8. JRDavisUF

    Implications of changing compiler version

    I just stumbled across one big difference when I use the newer compiler...which, as a nice side note, seems to explain my ctime issue issue as well. When I use the newer compiler, time_t now gets defined as a 64bit variable (versus the 32bit one I was getting using the older compiler), which I believe is why the ctime function once again works correctly(see my other changelist-related post). Unfortunately, with ctime a 64 bit long long, Serial.print() no longer works, because output of a 64bit number isn't supported ... but one problem at a time...
  9. [MSP432][Windows10][Energia 21][Board file 5.23.1] Recently I've been struggling with a run-time error in a very simple program (converting time=0 to 1/1/1970 fails using ctime...granted it's not really an Energia thing, but it's available for use in my CCS builds of energia projects) using the latest code composer, energia and board file (BTW, I don't have this problem with the previous board file) for my msp432. I've figured out a way to "fix' my problem, but it's unclear to me what the implications of this change might be. By default, when I create a new project in CCS, the project is setup to use the GNU v6.3.1 compiler by default. If I use this compiler, my program compiles, but it's operation fails. In looking into the properties of the project, I notice that I have 5 (2 TI and 3 GNU - 1 GNU older than the default and 1 GNU newer) compiler choices in the tool chain. As such, I started changing the compiler to see what would happen with my non-functioning code. First, I started with the TI compilers. If I select either of them, I get a notice about the need for "manual" intervention in the compiler config. As such, I gave up on those. I then selected the oldest version of the GNU compiler (4.8.4). Switching to this version and my compilation fails. Once again, I have up on that one. As a last attempt, I changed to the newer version of the GNU compiler (7.2.1) and lo-and-behold, not only does my problem compile, but ctime now works correctly. Newer things are always better, right? The default (non-working one) and older (non-compiling) versions of the GNU compiler appear to be shipped with Energia while the newer (working) one appears to be shipped with CCSv8. As such, although I've fixed my problem, I'm wondering if switching is just going to lead to other problems as I'm assuming energia was vetted with the default 6.3.1 compiler. Anyone have positive/negative experiences with changing the compiler tool chain? As my program runs with the previous board file (but using the latest Energia 21 otherwise), might I just be better to switch to the older board file (and wait for a board file/compiler update with energia) but leave the compiler as the default 6.3.1 version? jrd
  10. JRDavisUF

    Energia/board upgrade changelist?

    OK, I think I know the problem now. It looks like time_t variable expected by ctime has changed from a 32 bit number to a 64 bit one (long long). (see my related compiler change post) In time.h ($USER\AppData\Local\Energia15\packages\energia\tools\arm-none-eabi-gcc\6.3.1-20170620\arm-none-eabi\include) If I make the following change: char *_EXFUN(ctime, (const time_t *_time)); to char *_EXFUN(ctime, (const long long *_time)); The the ctime function works correctly.
  11. I've a code I've been working on a while that has worked fine with an older version of the Energia and the board file. When I recently upgraded Energia to 21 and the MSP432 board to 5.23.1 a bunch of things broke. I was able to determine one set of problems was caused by the SPI Mode0/1 bug being corrected. That is, since spi mode0 and 1 were switched, I switched them in my code. When the bug got fixed everything spi-related broke until I switched the modes back (to what they should have been in the first place). My latest problem is that my usage of the RTC no longer works. Attempts to read/set the clock (internal and an external DS3231) are not working correctly. Setting the time to unix time 0, yields "Thu Apr 23 19:16:16 198054" Something funky with the year for sure. (as an aside, anyone have ideas on this problem?) So this led me down the path of trying to figure out what changes were made in the upgrades of Energia and the msp432 board file. However, I've not been able to find a good source of the changelist-type information relating to these two things. Can someone point me to this? I'm guess this might be in github somewhere, but it wasn't really clear to me how to get at this info. For example, figuring out where/when the SPI modes got corrected. Also, I think it would be helpful to have some kind of "upgrade guide" that people could reference. That is, for example, saying things like: "If upgrading from an earlier version of XXX, you will need to swap anything related to SPI Mode0 and SPI Mode1", etc.
  12. JRDavisUF

    Energia/board upgrade changelist?

    FWIW, I'm able to get ctime to work correctly if I switch from the default GNU 6.3.1 compiler supplied with energia to the GNU 7.2.1 compiler supplied with CCS8...not sure the implications of this change...so I started a new topic to talk about that
  13. JRDavisUF

    Energia/board upgrade changelist?

    So I've narrowed my code down to what is below. Using the latest Windows 10 Code Composer, the code works using Energia 21 / 5.6.3 but not with Energia 21/ 5.23.1...It kind of feels like a heap/stack size issue. Maybe the newer board file needs more memory for something...Any code composer experts out there? There used to be some obvious places to change such things...but I don't see them any more... #include<time.h> void setup() { // put your setup code here, to run once: Serial.begin(38400); // Thu Jan 1 00:00:00 1970 time_t time1=0; Serial.println(ctime(&time1)); } void loop() { } (I'll also note that if the time_t and Serial.println lines are moved to the loop, the code runs fine.)
  14. JRDavisUF

    Energia/board upgrade changelist?

    Downgraded Energia from 21 to 18 and the problem still exists. Downgraded the board file from 5.23.1 to 5.6.3 and problem goes away ...
  15. JRDavisUF

    Energia/board upgrade changelist?

    I don't really get it, but if I change my declaration of time1 and time2 in my example to include "static": static time_t time1, time2; Then time2 gives the correct answer at least... Thu Aug 1 14:43:24 -1920291 Fri Jul 31 20:41:48 2015
  16. JRDavisUF

    Energia/board upgrade changelist?

    Lots more digging and it looks there is a time_t related issue. While trying to debug the problem, I tried running this example: https://github.com/rei-vilo/DateTime_Library/blob/master/Examples/Date_String/Date_String.ino These particular lines; // Fri, 31 Jul 2015 20:41:48 GMT myEpochRTC = 1438375308; Serial.print("Using default local time = "); Serial.println(convertDateTime2String(myEpochRTC)); Output this: Using default local time = Sat Jan 6 19:29:16 -1905047 which is consistent with the problem I am seeing in my test code that outputs the incorrect dates: Fri Mar 5 12:50:20 -1920835 Wed Sep 8 05:11:40 -848351 //test code #include "time.h" #include "RTC_Library.h" void setup() { // put your setup code here, to run once: Serial.begin(38400); time_t time1, time2; String result1, result2; // Fri, 31 Jul 2015 20:41:48 GMT time1 = 1438375308; result1 = convertDateTime2String(time1); Serial.println(result1); // Fri, 31 Jul 2015 20:41:48 GMT time2 = 1438375308; result2 = (String)ctime(&time2); result2.trim(); Serial.println(result2); } void loop() { // put your main code here, to run repeatedly: }
  17. JRDavisUF

    Energia/board upgrade changelist?

    I'm using the MSP432 Launchpad (red). I2C seems to be working ok as I've got a oled display connected via the same I2C pins and that is working just fine. I've also tried swapping out the RTC module with an identical one and it's showing the same behavior, so it looks like some kind of software-related issue at this point. And FWIW, both the internal (on the msp itself) and external RTC (I2C) are showing the same behavior.
  18. JRDavisUF

    strptime not declared

    I tried editing the platform.txt file, but it didn't seem to do anything....that is, I could never see the -D.. appearing anywhere during the compilation process. I did try changing my compiler settings to directly include the -D... so that I could see where it was being used, but it didn't seem to make any difference and the error I mentioned still showed up. I did realize that the routine that uses strptime isn't used by my code, so I commented it out that whole routine and my stuff works fine...so at least for now, I can punt on this issue...thanks for trying though...
  19. JRDavisUF

    strptime not declared

    I'm using Rei Vilo's RTC Library: https://github.com/rei-vilo/DateTime_Library Under Code Composer 7.4 / Energia 18 / MSP432 Red Board 4.9.1 this library compiles works fine. When I switched to Code Composer 8.0 / Energia 18 / MSP432 Red Board 5.6.1, "strptime" seems to have disappeared. Anyone have any ideas on what happened? Libraries/RTC/subdir_rules.mk:9: recipe for target 'Libraries/RTC/RTC_Library.o' failed ../Libraries/RTC/RTC_Library.cpp: In function 'uint8_t convertString2DateTime(String, String, tm&)': ../Libraries/RTC/RTC_Library.cpp:88:59: error: 'strptime' was not declared in this scope if (strptime(charDateTime, charFormat, &_timeStructure) == NULL) ^ thx. jrd
  20. JRDavisUF

    Simultaneous SPI and SPI1

    I'm trying to get access to the second SPI bus/module in order to use both bus 0 and 1 at the same time on a MSP432 (Energia 18 / Code Composer) and ran into an issue with the best way to achieve this. Just to give a little background, I've got an SD card on bus 0 (Mode 0 SPI) and I'd like to put a ADC breakout on bus 1 (Mode 1 SPI) such that I don't need to worry the SD card clogging up the SPI lines when the 512 byte buffer gets written. I am able to use: SPI.setModule(1) to get access to the second SPI bus just fine...Should I be putting a set module command before the chunks of code which talk to SD or ADC drivers? This didn't seem very elegant, but I think it might work. Something like: loop { SPI.setModule(0) Write to SD Card SPI.setModule(1) Get ADC conversion } What I was hoping to do is use "SPI." (set to use bus 0) for the SD card libraries and "SPI1.*" (set to use bus 1) for the ADC libraries, however, SPI1 doesn't work. What seems to be the problem with SPI1 is the following code in SPI.cpp: /* C type function */ void spiTransferCallback(SPI_Handle spi, SPI_Transaction * transaction) { SPI.transferComplete = 1; } Note how this code refers to "SPI.*" regardless of whether I'm using SPI.* or SPI1.* What seems to be needed is some logic that executes SPI.transferComplete if the module is 0 and SPI1.transferComplete if the module is 1. I tried changing this code to run SPI1.transferComplete, then atleast the SPI1.* stuff works...although I'm guessing SPI.* won't work at this point. Is there a way to get this callback access to the value of spiModule? any advice would be appreciated, jrd PS I'll also note that I'm using the original energia libraries (black), but the new boards (red).
  21. JRDavisUF

    Simultaneous SPI and SPI1

    Simultaneous SPI and SPI1 works! I've an SD card on SPI and a ADC breakout board on SPI1. I've a small code to stream data from the ADC to the SD card and all looks good.
  22. JRDavisUF

    Simultaneous SPI and SPI1

    Thanks for the patch. SPI1 now works standalone. I'll try simultaneously SPI and SPI1 next.
  23. JRDavisUF

    Simultaneous SPI and SPI1

    Thanks for the patch. SPI1 now works standalone. I'll try simultaneously SPI and SPI1 next.
  24. JRDavisUF

    Simultaneous SPI and SPI1

    Just a quick thought to fix the SPI1 issue, maybe in SPI.begin something like if spiModule==0 params.transferCallbackFxn = spiTransferCallback0; else params.transferCallbackFxn = spiTransferCallback1; and then just have two transfer callback functions. .I hate having to modify the core libraries, but I could see something like this working.
  25. JRDavisUF

    MSP432 ADC14 Clock

    So I think I understand the SD problem. I amusing a non-ti-rtos way of accessing my SD card. My guess would be that the more ti-rtos-centric way of implementing things in the msp432 emt red libraries is conflicting with my non-ti-rtos sd card library. I was able to successfully install/compile the ti-rtos/fatsd example, so I know it's not a ccs/board/wiring/etc. issue. However, it's not entirely clear which direction I should head now. Should I try and get the fatsd example working under energia?, or does someone have an energia ti-rtos SD library already working with the msp432 emt red stuff?