Made myself a cheap flasher for these two modules.
You need an ESP8266.
The code is here: 
github.com/sthaugen/Rephone-KL02-swd
Happy coding 
The GPS bug is fixed in this included hex-file
viewtopic.php?f=71&t=6684
best regards
Steinar
Can you share the way you used to fix module firmware (I mean, was there some source code, or you just hacked around assembler)?
- IDE - Kinetis Design Studio 3.0.0 http://www.nxp.com/products/software-and-tools/run-time-software/kinetis-software-and-tools/ides-for-kinetis-mcus/kinetis-design-studio-integrated-development-environment-ide:KDS_IDE
- Library - KSDK_1.2.0 http://www.nxp.com/products/software-and-tools/run-time-software/kinetis-software-and-tools/development-platforms-with-mbed/software-development-kit-for-kinetis-mcus:KINETIS-SDK
GPS source code https://github.com/WayenWeng/Xadow_GPS_v2
NFC source code https://github.com/WayenWeng/Xadow_NFC_v2
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
Uhm. Sorry, I just quick-looked at the code, and didnāt open commit history 
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.
ā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).
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.
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.
I got it all figured out. What was not clear to me was the the code which was being flashed was being flashed to the GPS xadow part, not to the RePhone part. Nothing was explicit about it, and I thought the gps part simply was the part on the xadow board. Once I realized there was a microprocessor on the GPS xadow board, I realized the flashing routine was referring to THAT part.
I have successfully flashed the updated code following the directions above, and the coordinates are correct for longitude now. I used a Adafruit 8266 Huzzah part.
Hi, I am newbie when it comes to working with microcontroller. Can we use an Arduino Zero or a Teensy board to flash the GPS firmware? I donāt have a board with ESP8266. I apologize in advance if itās a dumb question 
Alternately, can I use an FTDI cable to update the GPS firmware?
Technically it must be possible, however the uplodaer scripts must be adjusted. How: donāt ask me, I uploaded the firmware on my other modules with a JTAG, and itās a different story.
Yes, i used ESP8266, because it was 3.3 volts.
And so are Zero and Teensy.
It is plain Arduino code, except a function called yield() inside there, that is too avoid the processor entering watchdog reset.
Maybe you must redefine that, or comment it out.
Good luck
-Steinar