GPS Rollover MC7304

IoT Modules MC/EM Series
1

We have over 100 MC7304 modems out in the field affected by the GPS rollover. The modems are installed on systems running FreeBSD, but I can only find linux and Windows tools on the website for the patch.

Only GPS dates seem to be affected at the moment and luckily we can access the modems remotely, including having AT access to them.

Do you support other OSes? Any idea on whether we can patch the modems remotely on FreeBSD? Does the MC7304 support OTA updates and will that help with the problem we have right now?

2

Usually Linux files can be run on freeBSD. Please give it a try as below:

3

Applications, but surely not drivers? The Linux QMI SDK depends on GobiNet and GobiSerial.

I would have used whatever serial driver exists in FreeBSD, made sure it could bind to the QDL function on “boot and hold” mode, switched to this mode using the AT!BOOTHOLD command, and then used the simplest possible uploader code to push the file to the modem.

Building this on FreeBSD should not require too many changes: swi-update.c\utils - libqmi - QMI modem protocol helper library (mirrored from https://gitlab.freedesktop.org/mobile-broadband/libqmi)

Note that this code is very hackish, and is not really used by libqmi anywhere. It’s just in the repo for historical reasons. But the code is simple, and should work with a little hand holding from someone knowing FreeBSD.

1 Like
4

Thanks a load Bjørn.

I got the swi-update working in FreeBSD and successfully flashed the modem.

Changes made to the code for anyone interested:

  • Include sys/endian.h instead of endian.h
  • Add a type alias for __u8 to point to u_int8_t
  • Add a type alias for __u16 to point to u_int16_t
  • Add a type alias for __u32 to point to u_int32_t
  • Do not include linux/types.h and malloc.h

Once again, thanks Bjørn.

5

Hello Abdulwahid,

I have also compiled swi-update.c
Can you explain the arguments to launch it, do you have an example? Because i tried:

root@Cell_Router:/home/swi-update# ./a.out --help
swi-update (unknown)
usage: ./a.out [ --help ]–serial [image2] [image3]

root@Cell_Router:/home/swi-update# ./a.out --serial 1199:68c0 ./MC73xx_GPS_Rollover_2019_NVU.nvu
swi-update (unknown)
root@Cell_Router:/home/swi-update#

Thanks

6

You need to run the update in two steps, as Bjørn detailed above:

  • Set the modem to "boot and hold"mode
  • Flash the modem using swi-update

The modem exposes 6 ports, and these should be mapped to files on the /dev/ path as cuaUx.0 - cuaUx.5. The AT command port is the 3rd one, so cuaUx.2. Replace the x with your device number.

You can set the modem to “boot and hold” mode by connecting to the AT port via a utility such as cu or minicom and issuing the AT!BOOTHOLD instruction. Easiest way is simply:

printf "AT\!BOOTHOLD\r\n" > /dev/cuaUx.2

This will reboot the modem exposing only one port. So instead of cuaUx.0 to cuaUx.5 in /dev, you’ll have one file, cuaUx. This is the file you need to pass to swi-update.

Using your example, call swi-update as follows:

./a.out --serial /dev/cuaUx MC73xx_GPS_Rollover_2019_NVU.nvu

7

Thank you very much Abdulwahid,

as I have suceessfully made the 2 steps you said for my OpenWRT OS, according to this log :

root@Cell_Router:~# printf “AT!BOOTHOLD\r\n” > /dev/ttyUSB2
–> I have got the good reply “AT!BOOTHOLD” on the ttyUSB2 port.

root@Cell_Router:/home/swi-update# ./a.out --serial /dev/ttyUSB2 ./MC73xx_GPS_Rollover_2019_NVU.nvu
swi-update (unknown)
Got QDL version: 4
Downloading CWE image ‘./MC73xx_GPS_Rollover_2019_NVU.nvu’
CWE revision: 3
type: SPKG
product: 9X15
image size: 2228
version: INTERNAL_9901234_MC7355_00.00.00.00_00_GPS2019_001.099_000
date: 09/21/18

Waiting for ack
Success!
Terminating session - rebooting modem…

Then modem has well rebooted : I have recovered the 4G, Longitude, Latitude and Altitude, they are still OK.

But…
But the original problem of GPRMC date is still here, nothing changed, as today I am still on the 07/04/2000:
$GPRMC,081850.0,A,4748.587640,N,00157.311977,E,070400,0.0,E,A*0C

I have tried on 2 samples of MC7304 , and the result is the same. I tried yesterday and today.
Anybody knows what’s wrong ?

Thanks

PS : before this month November 2019, the GPRMC date was working well, and was according to Wikipedia :
https://fr.wikipedia.org/wiki/NMEA_0183

For example last month in october 2019 I got the good datagram for october 13rd:
$GPRMC,081850.0,A,4548.587640,N,00167.311977,E,131019,0.0,E,A*0C

And below is detail of the full datagram of today, with the GPRMC date issue remaining:

root@Cell_Router:/dev# cat < /dev/ttyUSB1
$GPGSV,4,1,14,01,64,108,30,03,75,272,18,11,52,154,24,17,41,298,267A
$GPGSV,4,2,14,18,31,19,25,313,22,22,76,053,23,23,247E
$GPGSV,4,3,14,28,08,255,15,32,07,036,18,06,01,298,08,02,167,*7B
$GPGSV,4,4,14,09,04,199,31,12,080,*79
$GLGSV,3,1,11,21,70,71,230,23,86,52,265,76,68,284,5C
$GLGSV,3,2,11,75,51,171,69,04,094,84,07,056,87,52,267,60
$GLGSV,3,3,11,85,33,046,67,02,345,68,11,032,54
$GPGGA,082435.0,4548.549403,N,00167.285392,E,1,04,5.3,180.3,M,48.0,M,54
$GPRMC,082435.0,A,4548.549403,N,00167.285392,E,0.0,34.7,070400,0.0,E,A3A
$GPGSA,A,2,01,03,17,22,5.4,5.3,1.031
$GPVTG,34.7,T,34.7,M,0.0,N,0.0,K,A23
$GNGSA,A,2,5.4,5.3,1.02B
$GNGNS,082435.0,4548.549403,N,00167.285392,E,AN,04,5.3,180.3,48.0,*6F

8

I suspect you got the wrong device specified. When the modem reboots after AT!BOOTHOLD, you’ll only get one port. So even though the swi-update says success, it’s not really uploaded the firmware to the modem.

Could you send me a screenshot of the files in \dev before and after you issue the boot hold?

9

You are right, I have tried again, and now it works!!!

For reference on OpenWRT OS :
Right, when I made printf “AT!BOOTHOLD\r\n” > /dev/ttyUSB2, during the reset of MC7304 I have lost ttyUSB0,1 and 2; then only ttyUSB0 woke up :
root@GL_OWRT:/dev# ls
(…) ttyUSB0

Also on port ttyUSB2, just before reset I got a nice answer “OK” as below :
AT!BOOTHOLD
OK

And after I have launched in 1 command line :
./a.out --serial /dev/ttyUSB0 ./MC73xx_GPS_Rollover_2019_NVU.nvu
swi-update (unknown)
Got QDL version: 6
Downloading CWE image ‘./MC73xx_GPS_Rollover_2019_NVU.nvu’
CWE revision: 3
type: SPKG
product: 9X15
image size: 2228
version: INTERNAL_9901234_MC7355_00.00.00.00_00_GPS2019_001.099_000
date: 09/21/18
Waiting for ack
Success!
Terminating session - rebooting modem…

and then it works, see below result :
$GPRMC,110414.0,A,4548.542142,N,00167.282237,E,0.0,221119,0.0,E,A*24
now I am in 22/11/2019.

So I advise to be careful when swi-update.c returns “Success!”, this is not the way to make sure that the patch has applied. Anyway, it works.

Have a nice week end, and many thanks again

10

Good to know it worked for you.

But I would not recommend using swi-update as a generic solution though, It’s a hack with almost no error handling etc, as you’ve discovered. You should use either the Sierra toolkit on the platforms where it is supported or the qmi-firmware-update from libqmi on Linux. FreeBSD is special since I don’t think it is covered by either, which is why I pointed to swi-update.

FYI: I wrote swi-update primarily for my own use, and never got around to clean and fix it up properly. But Aleksander did all the boring and hard work to make something useful out of it. That’s qmi-firmware-update . Which does work fine on OpenWrt and any other Linux system, and has a lot of fixes, proper error handling, firehose (EM7565 etc) support, and much more.

It is probably possible to make qmi-firmware-update work on other Unix systems too, by disabling some of the Linux specific stuff. But I assume it will be a bit more work, and not just a quick fix.

11

Hi dl5162,

I followed your instructions but I received an error like this:
root@xxxxxxx:/modbus/SWI# ./a.out --serial /dev/ttyUSB1 MC73xx_GPS_Rollover_2019_NVU.nvu

./a.out: line 1: syntax error: unexpected "("

Can you help to debug this issue? We also have few dozens 7354 running remotely and having the same rollover issues, and has been upset our customers. Please help us out.

Thank you,
Tony

12

I guess that I have to do cross-compile

13

Hi dl5162,

Cross-compiling doesn’t work to openwrt, can you show me how to do with libqmi?

Thank you,
Tony

14

Of course it does. That’s how OpenWrt is built. I believe it’s cross-compiled even for the x86 targets :slight_smile:

qmi-firmware-update is part of the qmi-utils package, which is included in the OpenWrt 19.07 releases. Simply install and run. It has much better built-in docs than I’m able to write.

15

Thank you for your response, But it has never been my lucky days, I tried all methods but not working, I have to recode by adding 7168 days to the gps days.

Best regards,
Tony