This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP 430F1611 & MSP 430F5438 code compatibility?

Hi,

I have code for an MSP 430 F1611 based product (.txt file). Can I just download it to a MSP 430F5438 based product without re-compiling? If not, what all should I consider changing in the code and recompiling.

If there is any app note that might help with this task, I would appreciate if some one can point me to it.

Regards,

Yogesh Gaur

 

 

  • Yogesh,

    This is quite a large undertaking.

    The serial ports are quite different.  (USCI versus USART)

    All of the interrupt vectoring is different.

    The clocking and power management is different.

    You'll have a fair amount of code rewriting.  It is not just a recompile job.

    A starting point might be SLAA395.

    Good luck!

    Jeff

  • yogesh gaur said:
    Can I just download it to a MSP 430F5438 based product without re-compiling?

    Definitely not. There are many differences. FLASH and RAM are on different locations (less flash, more ram in the lower 64k, additional flash above 64k), the usually used hardware multiplier has moved too. And the interrupt vector table has been expanded. So the plain code won't run at all.

    Then there ar emany changes in the processor itself. Besides the multiplier (which now supports 32 bit multiplications too), there is a different flash controller (requiring a rewrite of flash-writing funcitons), the USCI modules aren't compatible with the older USARTs (some code can be reused, e.g. the baudrate calculation, but init and interrupt management is different). Then there is a new and different clock module that is more orthogonal (ACLK and SMCLK are equivalent and can be sourced from both crystals) and has more features (FLL controlling of the DCO, internal 32kHz oscillator etc.).

    Interrups have ben generally changed to the scheme which was used on the 1611 only for the timers, using a vector register. Then there are no longer global module enable and interrupt enable registers. Everything has moved into the respective module registers and unified: One IFG and one IE bit for each interrupt cause.

    The ADC12_A is more or less the same, but with more channels and slightly changed registers. But there is no DAC12 anymore.

    I moved from the 1232 over the 1611 (which too was some change) to the 5438 too, and it was a major task. Most of the high-level routines didn't change (I already had a multi-level code library for the basic functions, so RS485 and RS232 fucntions all used the same UART low-level code), but the low-level stuff had to be rewritten mostly from scratch. With many improvements in effectivity :)

  • Hi Jens-Michael Gross:

    Thank you for the information this is very helpful. When you say large effort, was this about 6 months or 1 year or more -- for how many developers?

    Regards,

    Yogesh

  • Hi Jeff,

    Thanks for the information. This is very helpful. I will take a look at SLAA395.

    -Yogesh

     

  • Well, I can't exactly tell because I haven't actually finished the move and ahve been assigned to other projects, so it was just done besides the usual work.
    I'm the only firmware developer here and now I also assist in the Flash/Flex development of the PC application.

    When I started the migration, I didn't know (or care for) this forum and the 54xx was quite new too. Since then many pitfalls I had to fight are known, and the DOCs have been improved. Anyway, after about 3 months I had the core low-level stuff mostly working and was in the process of implementing additional things I didn't have at all on the 1611 (such as DMA burst transfer for the SPI, for writing/reading SD cards - actually it was a faulty documentation of the DMA controller which brought me here)

    you have the advantage of many issues alread known yet, so it shouldn't take TAHT long. After all, the basic principles are still the same. It is still an MSP, no ATMega or PIC :) (moving from PIC to MSP was a real pain, but it paid back soon)

  • Hi Jens-Michael Gross:

    Thanks for the information this is very helpful.

     

    regards,

    Yogesh Gaur

**Attention** This is a public forum