Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JRDavisUF

  1. Looks like -Os has returned in 5.25.1
  2. https://github.com/energia/msp432r-core/issues/34
  3. https://github.com/energia/msp432r-core/issues/29
  4. FWIW, I believe modes 2 and 3 should be swapped too.
  5. With the 5.25.0 msp432pr board file update, my SPI stuff has stopped working. Some time back, there was an issue with spi modes 0/1 being switched. As such, that was the direction I was looking to try and figure out my current problem. While digging around I noticed this: 5.23.1\cores\msp432r\ti\runtime\wiring\SPI.h #define SPI_MODE0 SPI_POL0_PHA0 #define SPI_MODE1 SPI_POL0_PHA1 #define SPI_MODE2 SPI_POL1_PHA0 #define SPI_MODE3 SPI_POL1_PHA1 5.25.0\cores\msp432r\ti\runtime\wiring\SPI.h #define SPI_MODE0 SPI_POL0_PHA1 #define SPI_MODE1 SPI_POL0_PHA0 #define SPI_MODE2 SPI_POL1_PHA1 #define SPI_MODE3 SPI_POL1_PHA0 If I swap the definitions for SPI_MODE0 and SPI_MODE1 my code works again. So has the mode swapping problem re-appeared?
  6. In the most version of the MSP432R board file (5.23.1 -> 5.25.0), the optimization levels were changed from -Os (optimize for space) to -O0 (no optimization). As a result, my code chokes on an error in CCSv9.1 which looks like this: `.rodata' will not fit in region `FLASH' c:/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major-win32/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 29204 bytes I'm able to fix, by changing the optimization level in CCS via the attache pic, but I was wondering, is this a permanent change? Was there some technical reason for it? Will it be permanent? thx. jrd
  7. I was able to figure out the issue and a work around. Turns out that the problem was Energia-related, not CCS specifically. In the most version of the MSP432R board file (5.23.1 -> 5.25.0), the Energia folks switched from -Os (optimize for space) to -O0 (no optimization). As such, I believe when I was upgrading versions on my code, I created a new project, which used the new compile option which blew up everything.
  8. My Win10 Code Composer v9.1 (which had been up-to-date yesterday) came up with a needed update today...so I ran it. Now, my Energia(21)-based code (msp432p401R) is splitting out this error (built using "debug"): `.rodata' will not fit in region `FLASH' c:/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major-win32/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 29204 bytes Somehow, with this new CCS update, my flash usage has increased by 30k (pretty significant given the limited about of space on the msp432s). Anyone else run into this? Is there some compile option which I need to tweak to get it back to the previous flash footprint? thx. jrd
  9. OK. I'll see what I can do to help. I just bought one, so we'll see how it goes! I see 5.25 has the P4111 as an unimplemented variant. Where can I find the source for the board files in github? I tried this location but its 5.6.1: https://github.com/energia/msp432r-core/tree/master/variants/MSP_EXP432P401R
  10. So is Energia itself dying/dead? There doesn't appear to be much going on...we are pushing a year since an upgrade...The P4111 has been out for over 2 years with claims by TI to be supported by Energia and it still isn't and doesn't seem like it will be any time in the near future. Is this a lack of interest by TI? Are they planning on dropping the Lauchpads? A lack of support in community? ... or has the product just sort of reached it's natural life and people have moved on. I like the product, but I'm beginning to feel alone in the world
  11. According to MSP432P4111 Launchpad User's guide (Revised Jan 2019: http://www.ti.com/lit/ug/slau747b/slau747b.pdf) Page 22: "Your device is also supported by the Energia IDE" However, I see no mention of the P4111 in the board manager 1.8.7.E21 (Win10) ...only the P401R and the E401Y. Is this board actually supported? ...perhaps by selecting the P401???
  12. 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.
  13. 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?
  14. 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.
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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...
  20. 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.
  21. 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
  22. [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
  23. 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.)
  24. 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 ...
  25. 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
  • Create New...