Jump to content
43oh

tml

Members
  • Content Count

    72
  • Joined

  • Last visited

  • Days Won

    4

tml last won the day on February 1 2017

tml had the most liked content!

About tml

  • Rank
    Level 1

Recent Profile Visitors

659 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 w
  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
  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 understa
  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
  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.ph
  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...