mcafzap

Members
  • Content count

    11
  • Joined

  • Last visited

  • Days Won

    1
  1. It's beginning to look a lot like a watchdog timeout... .and time to change to CCS from Energia.
  2. I'll be kind although it was ages ago: use the RTC_B library.
  3. Am I missing something obvious? To save power I want to run this processor at 1 MHz so I amended the boards.txt in Energia 18 as follows: (see below, the second half). The sketch does work at 8MHz and 16MHz. An related question is this: where is F_CLK specified in an Energia sketch imported into CCStudio? MSP-EXP430FR5969LP.vid.0=0x2341 MSP-EXP430FR5969LP.pid.0=0x0c9f MSP-EXP430FR5969LP.name=MSP-EXP430FR5969LP MSP-EXP430FR5969LP.build.mcu=msp430fr5969 MSP-EXP430FR5969LP.build.f_cpu=8000000L MSP-EXP430FR5969LP.build.core=msp430 MSP-EXP430FR5969LP.build.variant=MSP-EXP430FR5969LP MSP-EXP430FR5969LP.build.board=MSP-EXP430FR5969LP MSP-EXP430FR5969LP.upload.tool=dslite MSP-EXP430FR5969LP.upload.protocol=dslite MSP-EXP430FR5969LP.upload.maximum_size=65536 MSP-EXP430FR5969LP.upload.maximum_data_size=2048 MSP-EXP430FR5969LPmhz1.vid.0=0x2341 MSP-EXP430FR5969LPmhz1.pid.0=0x0c9f MSP-EXP430FR5969LPmhz1.name=MSP-EXP430FR5969LP_1MHz MSP-EXP430FR5969LPmhz1.build.mcu=msp430fr5969 MSP-EXP430FR5969LPmhz1.build.f_cpu=1000000L MSP-EXP430FR5969LPmhz1.build.core=msp430 MSP-EXP430FR5969LPmhz1.build.variant=MSP-EXP430FR5969LP MSP-EXP430FR5969LPmhz1.build.board=MSP-EXP430FR5969LP MSP-EXP430FR5969LPmhz1.upload.tool=dslite MSP-EXP430FR5969LPmhz1.upload.protocol=dslite MSP-EXP430FR5969LPmhz1.upload.maximum_size=65536 MSP-EXP430FR5969LPmhz1.upload.maximum_data_size=2048 sketch_mar29a.ino
  4. I was using 'SPI.end()' at the end of each read or write method/subroutine but I had noticed on the 5969 and the cc3200 that I had to re-declare the mode, speed and bit order. In the case of the 1310, I initially solved the problem by re-starting the bus with SPI.begin(), but simply excluding all references to SPI.end() is better. Thank-you for your response. It just goes to show you should sleep on a problem first before posting.
  5. I'm trying to use a cc1310 with a pressure sensor (BMP280) using the hardware port. I check at address 0xD0 for the chip ID (0x58) and this works but beyond this point there is no further SPI activity although I need to set up the filters and over-sampling etc. It's looking like I'll have to switch to CCS, but before I do, has anyone had this same problem and found a solution? BTW, this same sketch works fine with cc3200 (not emt) and the 430FR5969 which suggests a multi-tasking connection. Steve
  6. Here's a simple timer interrupt example from fduignan : http://ioprog.com/2015/03/20/using-timer-interrupts-with-the-energiamsp430-ide/
  7. Having spent some time thinking about this, I'm undecided. Simply setting a flag before transmitting and clearing it when done, does the trick. Testing this flag in the interrupt routine prevents the reading of data. It would be unnecessary if interrupts are not used. (I needed to use interrupts to minimise power.) BTW, thanks for your efforts - it has saved me a lot of time despite my problems. Steve
  8. Unfortunately you are absolutely correct! My problem was caused by allowing the receive routine to be triggered by the TX buffer empty signal, hence my original post. Thank-you very much for that.
  9. The main reason I use interrupts is to transmit many more than 32 bytes. When the device has emptied its transmit buffer the IRQ only goes low very briefly, so polling for it won't work AFAIK. Pseudo code: flag =1; radio.print(block1); radio.flush(); while (flag) ; //.. loop/repeat ad infinitum Int flag = 0; You can do a similar thing for the RX interrupt - set a flag and let the main loop handle it later.
  10. Just a word about using this with interrupts... . Using the interrupt to trigger a receive routine saves having to check (via SPI) on the state of the input buffer of the 24L01. However, if elsewhere in your program you transmit data, an interrupt will also occur when the transmit buffer is empty. In short, your interrupt routine must check whether you are transmitting or receiving because reading the input buffer whilst transmitting really messes things up. I apologise if some find this obvious, but HTH Steve
  11. I'm using a FR5969 board (Rev 2) with Energia version 14 on a Mac running OS X 10.10.1. My sketch uses a 32767 byte block of the device's 'ROM' for storage and in total the memory used is given as 46667 bytes of 65536. So the initial part of my code includes: #define PERSIST __attribute__((section(".text"))) and later... uint8_t TTFX[32767] PERSIST The program seems to run correctly except that I'm concerned about a warning: 'Assembler messages: C:\Documen~1\TBA\LOCAL~1\Temp\\ccAA9W6Q.s:1758:Warning: ignoring changed section attributes for .text (Actually, it produces the same error on Windows XP.) What I'd like to know is what is this error and if it's safe to ignore (must be incredibly doubtful). TIA Steve