Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JRDavisUF

  1. Just installed in the latest Energia and then used the board manager to update my msp432r stuff to the latest 5.29.0. However, in: AppData\Local\Energia15\packages\energia\hardware\msp432r\5.29.0 the platform.txt file says: version=5.25.2 version.string=5252 Is 5.29.0 the same as 5.25.2?
  2. Looks like -Os has returned in 5.25.1
  3. https://github.com/energia/msp432r-core/issues/34
  4. https://github.com/energia/msp432r-core/issues/29
  5. FWIW, I believe modes 2 and 3 should be swapped too.
  6. 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_
  7. 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 cha
  8. 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.
  9. 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). An
  10. 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
  11. 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
  12. 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???
  13. 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.
  14. 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?
  15. 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 (, 8.0.0.
  16. 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 wer
  17. 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
  18. 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
  19. 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 me
  20. 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...
  21. 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.
  22. 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
  23. [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 projec
  24. 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; S
  25. 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 ...
  • Create New...