Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


tml last won the day on February 1 2017

tml had the most liked content!

About tml

  • Rank
    Level 1

Recent Profile Visitors

529 profile views
  1. @@roadrunner84, thank you for your extraordinary patience while explaining these really basic stuff I should have been more precise: what I meant was: "Is there any reason for clearing the flag after instead of before execution of the function() " I guess it does not matter, anyway.
  2. OK, thanks! So this looks like what I was refering to in my last code snippet. Is there any reason for clearing the flag after the execution of the function() - provided this function doesn't check the flags? Like the interrupt flags, they are very often cleared upon ISR entry before any other interrupt is queued.
  3. Hi, This is really about basics, however if I don't ask I won't know the answer ;-) How do you deal with LPM and ISRs in a clean and readable way? Say you have a product that does measurements on multiple sensors; one are I2C ones, the other are ADC-based, yet the other are simple timer-capture-based impulse counters. They basically should work sequentially, not simultaneously. The problem I have is like this (pseudo code): 0: { 1: setUpSensor(); 2: enterLPM0(); 3: startMeasurement(); 4: enterLPM0(); 5: } ISR1() { .....; exitLPM(); } ISR2() { .....; exitLPM(); } Now, at line 2 we enter LPM0 and wait for the sensor to return from the setup procedure, say we assume it triggers some specific ISR that shall do something and exit the LPM at the end causing the program resume (as of line 3). Then it goes into startMeasurement and the LPM, waiting for the other ISR to do something and then exit LPM. Now, without any conditions after enterLPM() the program will resume with any exitLPM() routine call, any ISR can trigger it. We can have ISR1() to set some variable to be checked to proceed, like: 0: { 1: setUpSensor(); 2: enterLPM0(); 3: while (!setup) 4: { 5: startMeasurement(); 6: enterLPM0(); 7: } 8: } ISR1() { setup = 1; exitLPM(); } ISR2() { .....; exitLPM(); } This is going to keep the program running until the setup is false or 0, but it can eventually kill the program if the setup is never set for any reason (e.g sensor defect). Having just checked the condition: 0: { 1: setUpSensor(); 2: enterLPM0(); 3: if (setup > 0) 4: { 5: startMeasurement(); 6: enterLPM0(); 7: } 8: } ISR1() { setup = 1; exitLPM(); } ISR2() { .....; exitLPM(); } makes it necessary to put the conditions to all other code so the program does not continues from line 7 when exitLPM() is called (when the program was paused at 2) but the setup = 0 This all makes it more and more complex as we add another ISRs, checking the conditions becomes a nightmare. What I do in my program is indeed checking the flags set up in the corresponding ISRs and disabling the interrupt enable of the particular modules when their support is completed, this way they don't trigger ISRs when they are not expected (i.e when I finished measuring the pressure at I2C I disable the I2C interrupts and simply enable them when I want to do the measurement). The last one is tricky, it does work for me but doesn't protect me from the situation when I forget to disable some interrupt. What is your way? How is it done in the complex systems (yet not having the operating systems?). Is it disabling all interrupts at start and having them enabled just when they are used and disabled right after they are not used until next measurement, or is it using these flags set within ISRs and then checking them in the code? I don't believe my solution is correct.
  4. Hi! My first weather station that I've presented in this topic has been successfully working in the field since the deployment in September 2014 until early April 2015, when something failed and it stopped communicating with the world. I'll see what happened, I just need to bring it down from the 20m tall tree :-) In the meantime I've been working on the new hardware and I've finally completed it. The enhancements comparing to the 1st version are: added on-board lead-acid battery charging circuit (based on the Texas Instruments bq24450 chip) added support for microSD card (to store the pictures from the VGA camera and move the bootloader to make use of microSD instead of internal MCU flash) added GPIO-controlled 5V circuit based on LT1763-5 (also attached to the Launchpad 5V pin) added support for 5V UART with BSS138-based logic level translation (between 3.3V and 5V) - taken from the Sparkfun project moved modem's reset line to ADC-capable GPIO (this line is tricky, will probably later elaborate on that) added on-board voltage dividers to measure battery and solar cell voltages (in the first version I had them externally connected making the mess in the case) replaced SMA connector with u.fl The PCB size is 7x10cm, it was produced again at seeedstudio. I was taking care for assigning the GPIOs for the sensor so that they don't collide with CC3100 BoosterPack (in case wifi is needed instead of GSM). Well, it wasn't without issues unfortunately. The BSS138 circuit forwards some (330uA) current into 5V circuit, I should have inserted a Schottky at the R17/R18. I have made 10 PCBs (by mistake, it was meant to be 5 ;-) ), if anyone is interested in having some (bare ones, i.e unassembled) please let me know. It's an open hardware project, for now I've attached the schematics in PostScript because sharing the KiCAD project is not trivial - I have a mess in the component library :-) I'll do it some day. Also I will publish the source code, for now it's not something I'd like anyone can see, if you know what I mean.... Best Regards, Tomek meteo_mainboard.ps
  5. You don't know how happy this makes me that my 1st open source project is useful for somebody! All you need to do is from the host application to store the proper image on the download area of the MCU's flash and then manage the bootloader flags. If you had any problems please let me know.
  6. Fixed the link in the main post, sorry! I will need to rework the bootloader to add PetitFs + microSD supportso that it makes backup and reflashes from the SD, not the MCU flash. This way the working image size can be extended to MCU flash size minus bootloader coode size. So if you planned similar functionality and can open the source that'd be great! :-)
  7. I will be happy to do that soon. I'd like to move the data to some other place anyway (I'm not happy with the service I use now) and was thinking about IoT data servers. Do you know any that would allow not only to post data to but also get data from? I need to provide a configuration and firmware in ihex format for the weather station which it downloads each time it sends the data to the server. I need to be able to upload this config file and ihex firmware image.
  8. Thanks Bluehash! As for the current PCBs: I will of course share the design files soon (I need to clear up the working directories, see what's needed and what is not). But, the board has couple of issues that I described in the post. I plan to share the fixed version as well, but now I need to spend some time with my wife and daughter This project sinked me a lot!
  9. Hi Folks, Some time ago in a thread http://forum.43oh.com/topic/5550-simple-msp430f5529-bootloader/ I shared my bootloader that I wrote for my weather station project. I'd like to share some info on the project that I have completed and that its now operating in the field. Link to the description: http://eltomek.blogspot.com/2014/10/diy-weather-station.html All comments are welcome. Thanks all from this forum who helped me in numerous posts where I had no idea how to get out of technical issues! Best Regards, Tomek
  10. Thanks for good words! As for jumping to 0x1000 it's ok but it needs a sane application - if a damaged one gets flashed it will be unable to jump to BSL for recovery. Best Regards, Tomek
  11. When I started thinking about doing the bootloader I indeed got interested in the BSL but then I found out over the websites that: 1. invoking BSL requires a physical reset (source: http://processors.wiki.ti.com/index.php/Custom_MSP430_BSL#Device_Startup_Sequence - " NOTE: The boot code will be only executed on hardware reset (pulling down the /RST signal). Software reset such as using watchdog timer, setting the PMMSWBOR or PMMSWPOR of PMMCTL0 will not trigger the boot code.") 2. it needs to be written in plain asm (source unknown). I still don't know whether this is true and don't understand why can't this be written in C. I did not dig into this question as I decided to go with the current form of the bootloader. If you can put more light onto this I'd be more than happy! Best Regards, tml
  12. Hi, I will definitely share all the details about my project when only it gets done, deployed in the field and the code is polished to the minimum extent needed for it to be shown to the people ;-) Right now it's full of todos and hacks. I plan to release it as an open hardware and open software project, the first will be easier though. Best Regards, tml
  13. Hi, I have spent quite a significant amount of time to figure out how and then write a simple bootloader for MSP430F5529 that I would like to share with you. It was written for mspgcc (4.6.3) and uses small memory model; for accessing high flash (20-bit addressed) I use some simple assembler inlines. It won't work out of the box in CCS. This project is fully functional and I use it to remotely reflash my weather station (https://plus.google.com/u/0/photos/102121325118286323880/albums/5936572393229426625?authkey=CJ3N8Y2CtJiOIQ). I just push the new application image onto the web server, then the application working on the target device downloads it, parses and puts onto the flash and then lets the bootloader do the rest of the work. The methods used for reflashing are kinda primitive (e.g. word access, while the block write would be way more efficient), anyway, I had to have this up and running in reasonable time. I think making the code CCS-compatibile is not a big deal, the main part is flash access enclosed in flash.c. Moving code to RAM is even simpler in CCS with LOAD and RUN directives. Anyway, any issue reports and comments are welcome! repo url: https://bitbucket.org/eltomek/msp430bootloader Best Regards, Tomek EDIT: fixed the link to the repo.
  14. As for the mspgcc 4.6.3 I painfully got to know it doesn't support it :-) Possibly after turning on the optimization (don't know yet, didn't check), the far rom access function based on inlined assemblies stopped working properly and I thought CCS will be a better solution. But somehow I still feel gcc would be better for me if only it supported access to far rom from the C level. As for the memory model for the sake of efficiency I would rather stick to small memory model and just declare some pointers as 20-bit ones, like mentioned at http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#Data_type_attribute___a20__
  15. Hi, I got tired fighting with inlined assemblies to get the access to ROM over 64kB and after thorough considerations decided to move to CCSv6. But, I noticed that CCSv6 brought cooperation with MSP430 GCC (http://www.ti.com/tool/msp430-gcc-opensource) into CCSv6 and I wonder is this compiler will support 20-bit addressing natively (with memory model) as opposed to inline assembly. Do you have any experience with it? Best Regards, tml
  • Create New...