HL8548 and AT+IPR=115200 crash and reset

IoT Modules Legacy HL Series
1

Hi Folks,
We are using a HL8548-G module and have been having a lot of instability issues. Sending some commands will just cause the module crash and reset/restart

The latest issue we have found is that if we send AT+IPR=115200 when the module is already at 115200 baud will crash and reset.

We have observed that this happens more often if the command is sent quickly, so sending at a rate faster than once second will cause it to crash/reboot very quickly.

Here is an example with the commands being sent by a me clicking my mouse as quickly…

AT+IPR=115200
OK
AT+IPR=115200
OK
<Crash / reset>
+SIM: 0
+SIM: 1
+KSUP: 0
+WDSI: 0
+PBREADY
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
<Crash / reset>
+WDSI: 0
+SIM: 1
+KSUP: 0
+PBREADY
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
AT+IPR=115200
OK
<Crash / reset>
WDSI: 0
+SIM: 1
+KSUP: 0
+PBREADY

So pretty easy to repeat and fairly repeatable.
I did a loop to send the command 200 times with a 5 second delay and it crashed once.

The commands are being send over the UART and the USB is not connected.
Firmware is 5.5.25

Any one else having similar results?
Even better any one else using a HL8548, can you repeat this and see if it happens for you?

Regards,
Mark Leman

2

Hi Mark,

I can see the crash with 5.5.25 when repeat AT+IPR=115200 around 200 times during module startup / registration.

My workaround is delay sending AT+IPR=115200(repeat), i.e. after module get network registration. Then no crash any more.

My crash result is:

AT+EXCEPT

+EXCEPT: ID:0 Class:0XDDDD(SW GENERATED TRAP) Time: 2014:1:1 22:9:35

Register:

USR r0=0x17000000 r1=0x0008FCF4 r2=0x00000002 r3=0x0008D800

USR r4=0x0008FCE0 r5=0x000000C8 r6=0x0008D800 r7=0x603DDA90

USR r8=0x00000000 r9=0x00000000 r10=0x603D3EA8 r11=0x00000000 r12=0xFFFF80C4

FIQ r8=0x37668A4A r9=0x58FC3B5B r10=0x4EBE998C r11=0x840A9B43 r12=0xDFEF966C

FIQ SP=0x60A42688 LR=0x0840670C | USR SP=0xFFFF3B20 LR=0x38EBE5C3

IRQ SP=0xFFFF2F40 LR=0x632CF2B4 | MON SP=0x62A161A5 LR=0x815DFAD7 | SVC SP=0x603DDA90 LR=0x000805E4

DFAR=0x17000000 DFSR=0x00000005 CPSR=0xA00000D3(SVC) PC=0x0008060C

File: sio:sio_glue.c Line: 1448 SWID: 200
,

3

Hi Sierra_klin1,
Thanks for the reply. I am relieved you managed to repeat the symptoms, I though I was going mad ;-).

To do these tests I use a utility called ‘AT command tester’ which can script them, I tried

LOOP 200
AT+IPR=115200
WAIT=5 (the wait is in seconds)
LOOP-END

And I got one crash, but when I did this (which sends at a rate of about 1 per second)

LOOP 200
AT+IPR=115200
LOOP-END

I got 10 crashes. And if I click my mouse to send the commands at a rate of about 4 per second I can get it to crash every time within 2-5 clicks.

I also observe that AT+EXCEPT shows the error to be in
“File: sio:sio_glue.c Line: 1448 SWID: 200”

The problem is that just adding a delay after start up does not fix this. I have had it happen sending ‘AT+IPR=115200’ when the module has been powered and running up for >48hours.

To me it is a sign of a lower level problems in the Module firmware, probably in the saving and reading the settings from flash memory.

We have several modules returned from the field and some fresh from production which are very unstable and repeatedly crash, some can’t even find their SIM card. These appear to have corrupt settings and I believe these settings are causing the instability.

I do not know a method to do a ‘factory reset’ of all the configuration settings so I started to make a list of all the commands to reset everything back to default (suggestions welcome :slight_smile: ), I got to AT+IPR=115200 and bang the module crashes. This is not good, if I can’t even set the module back to safe/default settings how can be sure what state it is in.

We have also recently had an issue where just issuing the command AT+KTEMPMON? would reply +KTEMPMON: 255,255,255,255,255,255 and then the module would crash/erset immediately. This was fixed with the help of support by sending a command to reset the values (at+nvsed=bs.bs_ktempmon_config,0,1,000000001E0C). Again this looks like flaws in the handling of confuration settings in flash.

Regards,
Mark Leman

4

Our distributor , Solid State Supplies, helpfully called by with a HL module dev kit (Thanks Geoff :slight_smile: ) and we repeated the same experiment to rule out our hardware design.

The module was a HL8548 (not the -G we use), running 5.5.14 (from Memory I will confirm later).

Sending the commands using a script in 'AT command tester" and also “Teraterm” both caused the HL module to crash reasonably often (say every 5-10 commands).

I also tried in Hyper Terminal by cut and pasting a set of ~20 lines of “AT+IPR=115200”, but oddly this would not cause the crash/reboot. This perhaps shows the issue is related to the exact timing of the command.

Regards,
Mark Leman

5

@markleman,

5.5.14 is the very first release of firmware that came out on the HL8548 (4 years ago) and had quite a few issuesin it that have since been resolved and in fact 5.5.14 has been deprecated because of important fixes that have been implemented.

I have run 5.5.24.2 with the below teraterm script for 20 minutes (so I have no idea how many cycles but it would have been a few thousand) with the unit not experiencing an issue.

timeout=0

sendln "at+cgmr"
wait "OK"
sendln "at+cpin?"
wait "OK"

while 1
	sendln "at+ipr=115200"
	wait "OK"
endwhile

Regards

Matt

6

Hi mlw,
Thanks for trying that. I will update firmware in the module in the loaned devkit and repeat. This will have to wait till Thursday, off visiting a customer tomorrow.

I can repeat the crash/reboot 100% of the time on many examples of our hardware with 5.5.25, so I am expecting to be able to reproduce on the devkit with 5.5.25 too.

It was interested to note that scripts in 'AT command tester" and also “Teraterm” both caused the HL module to crash but Hyperterminal cut and paste did not. I suspect there is a timing related issue here.

The teraterm script I used was almost incidental to yours, I just looped 200 times.

Regards,
Mark Leman