NetBurner Community Forum

Hello,

I'm trying to implement serial update of our 5213-based product within our own Windows UI. The product uses a binary protocol, so we have serial update disabled by default to avoid unintended entry to the programming state. To update the 5213 flash from within our application, we do the following:

- stop our normal data collection
- send a binary protocol command that enables serial update in the 5213
- send the FC FC sequence that causes the 5213 to trap into the monitor
- send the S records from the _APP.S19 file

I'm sure that all of this is working correctly because after it completes, if I press the reset button on the device, the 5213 reboots and runs the new application.

My question is why doesn't the new application boot automatically after the last S record is sent? Does anyone know what, exactly, causes the monitor to recognize that the new program is complete and to then reboot? I assumed it was simply the S7 record at the end of the S19 file, but that doesn't seem to be enough.

Thanks,

Joe

I don't think that is exactly correct, it may be working, but the serial loaders is about 3X as fast.

It first converts the S19 into a binary image...

Then sends the monitor 0xBBBBBBBB
to put it in binary loader mode...

Then is sends the base address of the code block...

sends another 0xBBBBBBBBB
Then sends all the code, then sends 0x00000000

You may find all the code to do this in nburn\pctools\magicload\cprogramdialog.cpp

If you want to do it in srecord mode I believe that after you have recieved the last prompt send a reboot or a boot....


Paul

Thanks, Paul. I've got both ASCII and BINARY uploads working from our program. Here are my notes.

Both methods start the same way. Assuming an application is running and has serial update enabled, send FCFC (2 bytes binary). MOD5213 enters monitor and sends "Download S record, X to abort<CR><LF>Go:"

For ASCII, send the complete _APP.S19 file (with MTTTY or TeraTerm or your own application). For each valid S3 record (I think), the MOD5213 sends a single '*'. After the final (S7) record, the MOD5213 reboots and sends the boot message "Waiting 5sec(s) to start 'A' to abort".

For BINARY, send BBBBBBBB (4 bytes binary), followed by the 4-byte base address (msb first), and the MOD5213 responds with 'B' (for binary, I assume). Next, send all of the binary bytes of the new application, then send BBBBBBBB 00000000 (8 bytes binary) and the MOD5213 responds with "DB" (for done binary?), followed by the boot message "Waiting 5sec(s) to start 'A' to abort".

I'm using GetFileImage() from the file you referenced to get the binary image, which pads the image with extra bytes so total bytes is divisible by 4. When sending the 4-byte values, if any value is BBBBBBBB, another BBBBBBBB value is inserted to indicate that it's data, and not an escape sequence.

The MOD5213 supports Xon/Xoff flow control for both ASCII and BINARY transfers.