Wireless programming MSP430F5438

I'm not necessarily recommending this one way or another, but there is a  wireless programmer/debugger made by olimex if you are on a shorter schedule. 

Thanks for the quick reply. Actually I do have the time, so I want to implement something like this on my own without having to pay the big price. I don't necessarily need the debugging capabilities that this offers, but this is the main idea for what I actually want to do.

So if I'm understanding this correctly (and please bear in mind that I am merely a beginner at this), the steps are simply: 

• receive the data from anywhere (could be the wireless device, but its not clear to me if this is already implemented on yours)
• check each packet
• store it temporarily at some place in memory that doesn't interfere with the current program 
• check the overall CRC to make sure it received all the packages from the host, and let the host know when it did
• wait for "begin update" from host in order to copy all that data to the corresponding memory location
• reset device and start the freshly installed program

Jens-Michael Gross said:

During normal operation the device receives chunks of the new firmware, embedded into the normal data exchange.

With this approach, is it necessary to edit the BSL so that it can handle the wireless communication, or would the normal program take care of that. My assumption is that the normal program takes care of it, but I just want to make sure. 

Just to get the story straight in my head (because I am still unsure as to how it all works): The device will have to be set to a certain mode (much like the Chronos and its rf-BSL mode) previous to sending the code packets. Once the device is in this mode, it is ready to receive data wirelessly and store it in unused parts of memory (this operation is controlled by our custom BSL, so it needs to know a communication protocol between itself and the wireless device?). After checking that everything is received correctly, the custom BSL will write this data to the appropriate place in memory, reset, and start executing the new code. Is there anything I am missing??

Thanks a lot for the help! 

Alvaro Aguilar said:

• wait for "begin update" from host in order to copy all that data to the corresponding memory location
• reset device and start the freshly installed program

Alvaro Aguilar said:

With this approach, is it necessary to edit the BSL so that it can handle the wireless communication, or would the normal program take care of that. My assumption is that the normal program takes care of it, but I just want to make sure. 

But for the update function, there are three approaches.
- your application does it and it is part of the application firmware. This is unsafe as during update, teh function needs to replace itself, leaving the device vulnerable for some time.
- you replace the BSL by the update code, so it is executed on each reboot, checks for update data and does or does not do an update. It will remove the capability of an update using normal BSL functionality. And if you set the JTAG fuse to prevent readouts, you risk to make the device permanently unavailable.
- you put a double-buffered vector table and your boot code into the upper 1k of teh first 64k of flash.

Why the third? Well, your application will have changing vectors, which requires erasing and rewriting the vector table. But if you do so, there is a short window where there is no vector table and your device will never be able to recover for a sudden reset at this point.
So what I did is to place a generic vector table with a reset vector pointing to the update procedure and all otehr vectors pointing to an array of indirect jump instructions.
These instructions are of the type jmp &0xfbxx. Then I changed the linker script to put the 'real' vector table to 0xfb00 instead of 0xff00 and leave the last kb on its own.
The drawback is that every interrupt takes some additional cycles (for the jump) but the update process is 100% failsafe.
But you don't need a device with writable BSL area. It works with almost every MSP (except for the tiniest ones because of the 1kb size).

If you, however, update the device using JTAG, you'll need to include this bootloader into the project, since the JTAG update usually bulk-erases the flash and therefore the bootloader.

P.s.: the update function actually needs much less than 1kb, but more than 512 bytes due to the jumptable and vector table. And since it may not be erased ever, it occupies two full 512 byte flash segments. There is, however, some place for (string) constants that never change across updates, such as company information, device ID string/serial numbers or such things. Can be written once and never erased/changed again.

Well if I am understanding this correctly then it seems perfect! 

First let me introduce my scenario, and see if I understood what you said. I am basically developing a robot that other students will program in the future. For such a robot, I will write some libraries that allow the user to call certain functions that will make the controlling of the robot easier (i.e. a function like move(speed1, speed2, distance) or such would help the user move the robot around). In the end, the students will be debugging their code through the usual JTAG interface. However, once the projects are debugged, we want them to be able to switch the program on the device through the wireless.

Here is where your idea kicks in: On all their projects, the bootloader should be included so that it's always there after updating through the JTAG interface. Once the debugging is done and their project is ready, they can easily swap projects by using this interesting scheme.

Regarding the sending of the "code" packets: 

Jens-Michael Gross said:

The reception of the update data is done during normal operation. As part of the wireless protocoll that sends the data from the device to the access point or receives other information (setup, channel selection etc.). Of course the connection needs to be bi-directional for this to work. Devices which simply send their values every now and then won't be prepared to receive anything.

So basically we could use the eZ430-RF2500, which is going to be in place for the sending of sensor data to the PC anyway, to transmit the "code" packets to our main device, which would take care of putting them in the memory locations necessary.

Now, our MSP430 will be in constant communication with the eZ430-RF2500, which will mainly just pass the info to and from the PC. I hate to ask, but does this device need to have a different operating mode in which it sends the "code" packets only, or does this all happen during normal operation. I guess a better way of asking this is: does the eZ430-RF2500 know it is sending the "code" packets, or does it not distinguish what it is sending and only pushes whatever the PC is telling it to send? Or do we need to re-program the eZ430-RF2500 so that it can receive code from the computer, put it in the correct "packet format" for our program, and push it over to the target MSP430? 

Alvaro Aguilar said:

I hate to ask, but does this device need to have a different operating mode in which it sends the "code" packets only, or does this all happen during normal operation.

For our system, we introduced a 'timeslice, frame and package' protocol. Each device has a 'time slot' in which it may send. This slot is derived from a master (gateway or acces spoint). The master will also indicate the start of a slot cycle and he slot geometry (how many slots per cycle, hoe long a slot is etc.). This way a variable number of devices can communicate without collisions and there is no need to add a timestamp to the data (the gateway can do this) as the sending time is deterministic.
This approach needs a bi-directional communication as at least the synchronisation and the slot assignments need to be passed to the devices. (before you ask: there is an 'always free' slot which can be used by the devices after starup to introduce themselves and ask for a slot assignment). This setup also limites the maximum duty cycle for each device, which is needed by law for certain frequencies (can vary from 0.1% to 100% depending on frequency range and sub-channel and sending power)
This part is probably uninteresting for your application.

The frame, much like on low-level Ethernet, groups some packages (up to the maximum capacity of a single transmission, which is determined by HF data rate and slot size and the sending device itself - our has a 128 byte limit per burst transmission), adds a sender information and frame number (used if there are repeaters/range extenders in the system) and a CRC.

The single packages have a package type and package information. The size depends on the type. It may be as low as a few bytes or take up all the available space in a frame. Package types are server requests, configuration commands, slot requests, slot assignments and many more. The most often used one is the data packet, which contains a single value from a sensor, along with the sensor number on the sending device and a sending device ID, which is assigned to the device during the slot assignment (the gateway will save the devices serial number from the slot request and later replace the ID by this serial before forwarding the data through ethernet).
For initiating a firmware upload, sending firmware data or starting the update, as well as for the acknowledgements, there are different package types defined.

The transmitter (the RF2500) does not need to know what the meaning of the payload is. It just forwards frames of a given length in both directions. our transmitter (a 500mW 868Mhz transceiver) is dumb in this respect too. It just sends or receives a burst of data with a given length, not even knowing that this is a 'frame'. It just receives bytes through UART and starts sending when there are no more bytes coming for some time, or puts any received bytes out through UART. The precious transceiver was just sending high and low through a toggled I/O pin (and receiving the same way) yet the protocol was the same, only that not the UART ISR but the port ISR/timer ISR was receiving or sending the packets.
I don't know how the RF2500 works, bu tit should be no problem implementing something like that without needing to change the RF2500 firmware at all.

Hi again, sorry about the late reply... 

I finally had a chance to speak with my professor about our application, and he gave me a couple of pointers. For our special purpose, we do not want the memory restrictions or the timing delays for the interrupts. Therefore, I believe the best way to proceed for us is to modify the BSL on the MSP430F5438 on the board so that it can communicate through the SPI (or whatever communication peripheral is used) to the eZ-RF2500. 

If I am correct, my modified BSL would have to be able to take care of communication to the RF chip as well as RF configuration? The PC will send the BSL packets and commands via the eZ-RF2500 to the board, which should be in a special mode for this to happen. In this mode, the normal application will be stopped, and the board will merely wait to receive the packets in order to update the firmware on the device.

Any word on creating custom BSL's to perform such a function? 

Alvaro Aguilar said:

If I am correct, my modified BSL would have to be able to take care of communication to the RF chip as well as RF configuration?

You'll need a 5438A processor, as the BSL is not reprogrammable on the non-A types.
Then the space in the BSL section is limited, while you have to fit more into it (the RF chip init and transfer handling).
Also, you cannot use interrupts easily, as you have no way to put your ISRs into the interrupt vector table (it will and has to contain the vectors for the application).

The BSL must provide a function which determines whether to enter BSL mode or not. Normally, it will check the BSL entry sequence ('reserved' magic hardware bit), but in your case, you can go and implement your own criteria, such as a jumper on a port pin.

The 5438 has an option to move the vector table to the end of ram, so you can copy your own manual vector table (or only the used vectors) there and switch. Since the ram hasn't been initialized when the BSL is hit (the BSL runs before the c startup code is executed), and even the stack isn't, you can safely do with the ram what you want. Just don't forget to undo all config changes before you return control to the application.

There is, however, a problem: if the BSL is entered from software (manual PUC, bu tnot POR), some application interrupts may be still active. e.g. the TAIE flag isn't reset by a PUC, only by a POR. So Timer interrupts keep coming. The original BSL will not see an entry sequence flag if there wasn't a real POR before, and therefore only start if all is disabled.  But your version might be started from software. And it may not read the reset vector register to check, as this would possibly interfere with the applications init code, if the application wants to check the reset cause too.

It's difficult to fit all this into the limited BSL space. And it is even more difficult if you want to program the BSL in C language. Here assembly language is the better choice.

Once again thanks for all the help. 

I gather that entering the BSL mode through hardware rather than software would be better for me then if I want to avoid much hassle. Using a jumper on a port pin, or some kind of global interrupt that throws me into "BSL mode", where all other interrupts are disabled, might be best? 

I do have a bit of a problem coming up with the BSL code, and I was hoping to find some example code somewhere, can you point me in the right direction? I don't mind writing it in assembly, although i cannot assure that my version will be the most space-efficient...  Working off of an example might e the best for me...

Alvaro Aguilar said:

I gather that entering the BSL mode through hardware rather than software would be better for me then if I want to avoid much hassle.

Alvaro Aguilar said:

can you point me in the right direction?

There is, however, no hardware port pin or interrupt that throws you into BSL mode directly. The usual machanism is that after a reset, a function inside the BSL area is automaticvally called and this function checks and returns whether the BSL must be entered or not. The check is normally the BSL entry sequence (on serial BSLs the TEST pin toggle during the reset, on USB devices a certain, normally invalid USB condition). If you replace the BSL, you can also replace this function by your own which checks for a certain port pin or so.
But in any case, it is a RESET, that trigers the BSL check/entry. (unless your application just jumps into it, but then again, this is only an add-on: it needs to work too when your application won't run anymore)

Thanks for all the great input...

After thinking about this for some time I found one last solution that I would like to explore. Since I will be building a robot, I could mount the MSP430FET-UIF debugger onto the robot and have it always be plugged in to the JTAG port on the Experimenter's Board that the MSP430F5438 is sitting on. I would add a Bluetooth device that communicates with the debugger via the miniUSB port on it, and to the computer via a USB port. This means that all I would be replacing really is the USB cable from the computer to the debugger with a wireless link. In this manner, I could program (and debug) the board wirelessly? 

Additionally, I believe the pins on the JTAG port can also be accessed by the application, so this wireless link could be used as well for data transfer once the application is running. This seems like a good approach for me if it were possible. 

Alvaro Aguilar said:

I could mount the MSP430FET-UIF debugger onto the robot and have it always be plugged in to the JTAG port on the Experimenter's Board that the MSP430F5438 is sitting on. I would add a Bluetooth device that communicates with the debugger via the miniUSB port on it, and to the computer via a USB port.

Olimex offers some FETs with RF connection. There the receiver is plugged onto the target board, powered with 3.3V from the target (exact regulator required). The transmitter is an USB dongle on the PC. Works perfectly with msp430-jtag (mspgcc toolchain). And offers perfect isolation between target board and PC (critical for some uses). It alss removes any risk of ripping the JTAG cable from the target during operation. Or the need of looong cables if you cannot place the PC near the target.
I think our production engineer had it working with ~10m distance on some occasions.

Jens-Michael Gross said:

Olimex offers some FETs with RF connection. 

This was already suggested, and I looked into it but I am still not convinced because of the price. This is a student-designed robot, so keeping the cost down is a bit important. If all else fails, we could move to buying this solution, but for now I would like to explore the possibility of emulating it. We already have the MSP430FET-UIF debugger, so I was thinking why not just buy a wireless module to add onto it. Also, bandwidth is important to our project, which is why we wanted to go with Bluetooth. From what I see, the RF tool would have a BW similar to the eZrf-2500 (500 kbps).

For the same reason, I was wondering if my application could have access to the JTAG ports as General I/O ports when running. That way, I could use the same wireless module during application time as I used for programming.

Thanks.