(TECH) Upgrading/Flashing RePhone GPS/NFC modules firmware

[haugen.steinar]

Made myself a cheap flasher for these two modules.
You need an ESP8266.

The code is here:
https://github.com/sthaugen/Rephone-KL02-swd

Happy coding


The GPS bug is fixed in this included hex-file
http://www.seeedstudio.com/forum/viewto ... =71&t=6684

best regards
Steinar

[seeed86]

Can you share the way you used to fix module firmware (I mean, was there some source code, or you just hacked around assembler)?

[haugen.steinar]

1. IDE - Kinetis Design Studio 3.0.0 http://www.nxp.com/products/software-an ... de:KDS_IDE
2. Library - KSDK_1.2.0 http://www.nxp.com/products/software-an ... INETIS-SDK

GPS source code https://github.com/WayenWeng/Xadow_GPS_v2
NFC source code https://github.com/WayenWeng/Xadow_NFC_v2

[seeed86]

Thanks a lot!
Although, I'm pretty sure, community would like to see the sources of your changes to GPS firmware and, maybe it somehow speedup new "official" release

[haugen.steinar]

Thanks a lot!
Although, I'm pretty sure, community would like to see the sources of your changes to GPS firmware and, maybe it somehow speedup new "official" release

I just used WayenWeng 's repo, he did the update, you can see the change at his github

[seeed86]

Uhm. Sorry, I just quick-looked at the code, and didn't open commit history :/

[rhbroberg]

I am going to do the flashing as described at the top of this post, but after looking at the code (and the generated file from the python script), there's something I need explained to me. The hexfile from the gps code fix only contains gps code, yet the firmware is being erased and reflashed with no offsets that I can find. How does the flashing routine only update the part of the code which is gps-specific? There are address offsets in the hexfile starting at 0x1000 however those are the same offsets for the NFC hexfile - and those offsets are discarded when the code is generated by the python script.

[dbelam]

"How does the flashing routine only update the part of the code which is gps-specific?"

The flashing updates everything - every good flashing starts with full erasing the flash and then uploading the code. Of course most of the times the previous code is just overwritten, but I've seen countless times that flashing a microcontroller several times without erasing previous code could lead to faulty behavior (the lab in my university had ATmega128 based boards, and the same .hex worked after a full erase, which was not before).

[rhbroberg]

Which is why the flashing code doesn't make sense to me. Since flashing replaces *all* the code in the micro controller, and the only code in the hex file is the code from the gps module, that seems to be a problem to me, which is why I'm asking.

Or is the code posted in the hex file both the gps code *and* all the other code which makes up the micro controller firmware? If so, I would expect it to be larger. The hexfile for the posted gps code is ~59k, whereas the image.bin that the firmware uploaded processes is ~4.9M.

Don't we need a hexfile of the entire image to push to the part? If so, how/where can we build it, given that we only have source for the gps driver? If not, and a hexfile which only has 1 subsystem (in this case gps), how does the 8266 code distinguish between writing the GPS code vs. the NFC code (which is what the original post here indicates in the code)?

Wait a minute - is this flashing procedure what I do to the GPS part itself, and not the rephone 2502 part? If that's the case, then I understand the issue - I *am* erasing and flashing all of the flash on the GPS part. The directions did not make it clear that the code lived in the GPS part, I thought I was trying to flash the rephone part itself.

[dbelam]

Looks like you are a bit confused

This is a module-only code, does nothing with the 2502 core module, that's why is it only several k-s in size. It's flashed on the gps module, and it only does the gps stuff.

I'll explain everything as soon as I go to a PC.

So:
flashing replaces *all* the code in the micro controller
No - if you make just a led blinking example, it will be just 1k in size, while a GPS firmware is much bigger. It only overwrites the actual portion - so remaining code in flash (which should never be accessed normally) and badly written bits could happen without full erase. (also full erase mostly clears EEPROM and any other storage too)

Or is the code posted in the hex file both the gps code *and* all the other code which makes up the micro controller firmware?
We have a winner! A .hex is a complete firmware, with interrupt table, init code and main code. And don't be fooled by the size, they optimize so it will be sooo tiny. It's not an .exe, it's just pure application. The image.bin has also images and stuff like that in, don't forget!

If so, how/where can we build it, given that we only have source for the gps driver?
It's a wole project, but not for the rephone ide, but for the microcontroller built in the xadow module. Building that will need a different compiler with different settings. It's not a different subsystem: each module (except the breakout and sound) has its own intelligence: the core module has a huge ARM926 processor, and each xadow module has an own ARM Cortex M0(+) microcontroller. The rephone accesses the M0 microcontrollers, not the sensors directly! The GPS firmware means firmware for the GPS Xadow module's microcontroller.