Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by LIJsselstein

  1. Wow, what a process. Every small step forward immediately ends in another challenge. It also feels like there is unnecessary redundancy, as e.g. the capabilities of the mcu need to be defined twice (e.g. once for gcc and once for DSLite). Not having any experience with this stuff, I would like some advice about two things: 1) In the post above I mentioned that Timer0_A0 does not exist on the FR2433, but the TimerSerial and Tone libraries assume one is available on all MCU's. I think I fixed this by extending a few defines like this in TimerSerial.cpp: #ifndef TIMERA0_VECTOR #ifdef TIMER
  2. Finally made some progress: the FR2433 definition was missing in the msp430mcu.spec file (in hardware\tools\msp430\msp430\lib\), so I copied the definitions from the fr4133 in three places. Now the compiler gives the following error: The relevant code in TimerSerial.cpp is: #ifndef TIMER0_A0_VECTOR #define TIMER0_A0_VECTOR TIMERA0_VECTOR #endif /* TIMER0_A0_VECTOR */ #ifndef __GNUC__ #pragma vector = TIMER0_A0_VECTOR __interrupt #else __attribute__((interrupt(TIMER0_A0_VECTOR))) #endif //Timer0 A0 interrupt service routine static void TimerSerial__TxIsr(void) { TA0CCR0 += TICKS_
  3. I'm pretty sure that, in one of the many slau's I've read over the last days, there were hints about the eZ-FET 1.2 Emulation also being suitable to do BSL.... But never mind. Thanks a million Jazz! Your comment triggered me to try mspflasher again. I tried that route before only using the ERASE_ALL option instead of the ERASE_USER_CODE. Using the eZ-FET Lite on the G2 launchpad this resulted in an error code: Looks like the eZ-FET Lite does not support the ERASE_USER_CODE option. Trying the ERASE_ALL option resulted in "Could not find device (or device not supported)". So I
  4. I'm trying to use BSL-scripter to erase the FRAM on my custom board since it locked the Spy-By-Wire interface after uploading an incorrect firmware. So I connected the launchpad to the pc using USB, determined the application COM port (5) and hooked up the custom board to SBWTCK, SBWTDIO, RX and TX pins on the FET-side of the launchpad. Spying on the 4 pins is a logic analyser. The following script is used for BSL-scripter: According to SLAU610B there should be a toggle on TEST/RST to start the FR2433 in BSL mode (see figure 2), but BSL-scripter returns error 0x19 on TX_BSL_VE
  5. msp430-objdump -CD returns among a lot of other things: Disassembly of section .vectors: 0000ff80 <__ivtbl_16>: ff80: 5e c4 5e c4 bic.b -15266(r4),r14 ;0xc45e(r4) ff84: 5e c4 5e c4 bic.b -15266(r4),r14 ;0xc45e(r4) ff88: 5e c4 5e c4 bic.b -15266(r4),r14 ;0xc45e(r4) ff8c: 94 c5 5e c4 bic -15266(r5),-15266(r4);0xc45e(r5), 0xc45e(r4) ff90: 5e c4 ff92: 5e c4 5e c4 bic.b -15266(r4),r14 ;0xc45e(r4) ff96: 5e c4 5e c4 bic.b -15266(r4),r14 ;0xc45e(r4) ff9a: 5e c4 5e c4
  6. I haven't seen the error every time between my two reports and did not see it again after my last report. I'm sure that I wasn't looking at a cached version of the site the second time: I cleared the browser cache and loaded the page on multiple devices, some of which hadn't visited energeia.nu before.
  7. Yes, I noticed the difference and tried to come up with a correct offset. Even while looking at a few other mcu's I couldn't find out what the correct formula is. Anyway, later I found out that there is a memory.x file for each cpu that defines the base address for the vector table. E.g. for the G2553 it's: vectors : ORIGIN = 0xffe0, LENGTH = 0x0020 /* END=0x10000, size 32 as 16 2-byte segments */ And for the FR2433 I now have: vectors : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */ So - when my understanding is correct - in the ve
  8. So the next problem is pleasing the linker: According to some online resources I need to have the -mmcu flag correctly setup. In boards.txt is defined correctly so I was wondering... Then I discovered something new, there are also an XML-file and linker script (ldscript) directory for each mcu involved... These are added as well and building completes successfully now. Next I uploaded the basic blink sketch but it didn't toggle the pin so I changed some things and tried to upload again but this time I got: Oh deary me... It seems that at least one of the many many addres
  9. Note: this post has been edited, see at the bottom. So, to document the process, I've laboured through the msp430fr2433.h file and changed all the register definitions and checked their addresses with the datasheet. After that the compiler complained about This is the original vector table from the include_gcc directory in CCS: /************************************************************ * Interrupt Vectors (offset from 0xFF80 + 0x10 for Password) ************************************************************/ #define PORT2_VECTOR (42) /* 0xFFDA
  10. I try to add support for a new mcu (MSP430FR2433) to Energia and would like feedback if this is the right way... The boards and variants files have been already been adapted. Because Energia uses GCC also I copied the msp430fr2433.h from the TI CCS directory: \ti\ccsv6\ccs_base\msp430\include_gcc\ to the Energia directory: \energia-0101E0017\hardware\tools\msp430\msp430\include\msp430fr2433.h But when I try to build the basic blink example I get errors like Looking at this line and comparing it to the already existing msp430fr413
  11. Not sure if if its useful to report, but the foul language is back again at the Energia frontpage. Specifically the page: http://energia.nu. I get:
  12. Yeah, I got the explicit language error as well. Something with 'f*ck' a few times. Either a 'funny' admin or a hack....
  13. While installing CCS newly on another PC I noticed that the core header files for the FR2433 were available this time. So I reinstalled CCS on my daily machine and... tada!
  14. Thanks Jazz! I used this wiki page to upload your blink example and it works fine (remember to change the settings in FET-PRo430 from JTAG to Spy-by-Wire). Thanks again! Looking at the lnk_msp430fr4133.cmd file I notice that e.g. FRAM and RAM sizes are not correct so, following the same idea, I'm going to use the msp430fr2633 files as a starting point instead.
  15. @@monsonite , hope you don't mind me asking some questions unrelated to Chipstick (both the device or the food ) but the FR2433... 1) I've created my own board based on this MCU and would like to see a basic sign of life. So I opened CCS, created a new CCS project based on the 'Blink the LED' template, selected MSP430FR family and then MSP430FR2433 as target. I then tried to compile the code but it gives an error: "C:/ti/ccsv6/ccs_base/msp430/include/msp430.h", line 1784: fatal error #35: #error directive: "Failed to match a default include file" Checking the msp430.h file makes it c
  16. @@monsonite, can you tell where you get the MCU? I've checked with the major resellers in Europe (Farnell, Mouser, RS, DigiKey) and none sell the FR2433 VQFN24 package in small quantities. Thanks!
  17. I had seen that topic and the code snippet is wrong in my opinion. A break on RS232 is a prolonged LOW level (not HIGH as in this example). RS232 idle level is HIGH, see e.g. here: Also, to me it's weird that pinMode() is only used after the first digitalWrite()? Anyway, the above example is quite old. The custom endSerial() function seems to be replaced by current Arduino's flush() and end() functions. So I can rewrite the function as follows: sendbreak() { digialWrite(1, LOW); // Set pin to serial "idle" state. Serial.flush(); Serial.end(); pinMode(1, OUTPUT); digitalWrite(1, HIG
  18. Thanks both! Thanks for the Users Guide bit (I should have RTFM first ). While the code in the TS works, I'll try an implementation of that as well. I was transmitting on 57600 baud, so the break should be longer than ~1000 us, my 100 ms is a bit over the top admittedly Well, I'm not so sure about that. When the output is in high idle state (using digitalWrite) and then begin() is called, my logic analyzer sees a start bit: the level changes from high to low (few microseconds) to high again. Perhaps this is a side effect from attaching the UART logic to the pin?
  19. I've started this week using CCS to debug and analyse power consumption of my battery powered device using the Energia framework. CCS/EnergyTrace is a powerful tool when it works, however, I have one really really annoying problem with it: debugging does not work most of the time. When it works, pressing the debug button will break the code on the first line in setup() and EnergyTrace is running during debug. When it doesn't work, the device seems to be running and debugging seems to run, but it won't stop in setup() or other breakpoint I set, Pauze button is greyed-out and EnergyTrace is
  20. I have a custom board with a device hooked up to the hardware UART on a MSP430G2553 and need to send a break signal followed by a specific character and wonder how to do that correctly in Arduino/Energia. After some experimenting with help of a logic analyzer I came up with the following code snippet: // Start hardware serial communication Serial.begin(57600); /* Do stuff like Serial.print("blabla"); here */ // Ok, now we need to send a break to the other device // Stop serial communication Serial.end(); // Start break signal on MCU TX pin digitalWrite(P1_2, LOW); // Wait a while. M
  21. I've created a new board variant 'g2553_tssop28' in Energia and developed my project succesfully but ran into some difficulties trying to port a library for the Adesto AT45DBxxxx dataflash. In an attempt to get better debugging I imported the project in CCS and got the following linker error: At first the problem was caused because the digital_pin_to_analog_in array was completely missing in pins_energia.h but after I added it and rebuilt the project the error persists. I cleaned the project, refreshed it, rebuilt it, removed it completely (deleted the directory in 'Workspace')
  22. Amazing stuff greeeg, is this hobby or profession, having a 3d printer, cnc etc.? The 30V high side switches I use also leak up to 1 uA so if you have a few of them, for the battery voltage measurement and other chips/systems then this adds up. My battery powered system (9-30V) uses ~3 uA in LPM3 and setting all pins correctly high or low was key to that. Were you able to save significantly more by disabling internal functions? Regarding the uCurrent I wonder: will your device still be able to use (say) 100mA when you set it to the uA range? With a normal DMM the voltage drop over the
  23. Thanks again for helping me along! Things are currently still in breadboard stadium so line impedance will certainly change once the circuit gets translated into PCB. I'll add series resistors by default and tune them to match the board, keeping in mind that a cap might be useful if the resistors turn out not working well enough. I intend to have the SPI bus fan out to one or two separate boards later and read in the StackExchange link above that a cap near the middle of the wire (say near the connector of the MCU board) can help in that case. The whole setup is supposed to be low power a
  24. Thanks Greeeg, and you're right I don't have an EE background, it's primary in process control and automation. Interesting video, glad my chips didn't blow up in my feeble attempts Removing the caps (except between Vcc and GND on the Dataflash chip) and adding 47 Ohm series resistors on the data/clock lines as close to the transmitter as the breadboard permits seems to work.
  25. Thanks spirilis! This topic should actually be renamed to 'series resistor' instead of 'decoupling capacitor'. Your comment triggered some long forgotten training and Googling around gave some helpful pointers to refresh thing a little e.g. http://electronics.stackexchange.com/questions/33372/spi-bus-termination-considerations So what I really need to do is get an oscilloscope and add some termination resistors near each driving pin, in the 50 Ohm range you suggested. If that does't improve things enough than an decoupling capacitor might help.
  • Create New...