HL8548 CGATT=1 results in Unspecified GPRS error until CGATT=1 is called multiple times in a row

#1

HL8548 RHL85xx.5.5.25.0.201804161340.x6250_2

Strange problem we encountered with attaching to the network with a roaming SIM card. We go through a cycle of calling +CGATT=1 and receiving an ERROR response. The next step we take is going through a detach process, this seems to exacerbate the problem we are encountering. If we do not go through the detach phase and call +CGATT=1 one or two more times, it will eventually attach and get out of the issue.

When our device has the issue, it will rarely attach again unless we run through a different sequence. We are trying not to attach more than six times per hour in accordance with our carrier. However, the issue we see and the workaround we put into place may have us exceed this limit.

Below is the recovery sequence form power-on of the HL8548:
AT+CMEE=2

AT+CMEE=2

OK
AT+CGATT=1

AT+CGATT=1

+CME ERROR: Unspecified GPRS error
AT+CEER

AT+CEER

+CEER: “SM attach error”,111,"+NEER: Protocol error unSpecified : Cause #111"

OK
AT+CEER

AT+CEER

+CEER: “SM attach error”,111,"+NEER: Protocol error unSpecified : Cause #111"

OK
AT+CGATT=1

AT+CGATT=1

+CME ERROR: Unspecified GPRS error
AT+CEER

AT+CEER

+CEER: “SM attach error”,111,"+NEER: Protocol error unSpecified : Cause #111"

OK
AT+CGATT=1

AT+CGATT=1

OK

If there is nothing I can provide here, I can see about documenting our detach procedure. Keep in mind, for each time we run the module, we shut it down completely (remove power).

1 Like
#2

Hi robvice,

Could you check the following result and then try to select the network manually?
ATI3
AT+COPS=?
AT+COPS=1,2,“46001”,2 //UMTS

#3

Hi Sierra_klin2,

Unfortunately, the problem is not easily reproduced. Additionally, we have many devices traveling the world so adding in the detection and network selection piece is a lot of overhead to maintain.

AT+CGMR and ATI3 return the same result as I previously stated:
ATI3
ATI3

RHL85xx.5.5.25.0.201804161340.x6250_2

AT+CGMR
AT+CGMR

RHL85xx.5.5.25.0.201804161340.x6250_2

When the problem occurs, is there any other command I can run to get details on the GPRS issue?

#4

I suggest waiting the new release of FW v5.5.26 and check if issue can be solved your side.
( A PDP attach/activate request reject issue was fixed in the new FW)

#5

The issue has “bricked” devices unless the attach is called multiple times without going through a detach sequence.

Is there an anticipated release date? I would like to run it on ~100 of our devices and see if the issue goes away with our firmware that raised the issue.

#6

Note: This specific reply appears to be a hardware issue with the radio. I cannot get it to attach at all.

On one device, running COPS=? returns
AT+COPS=?
AT+COPS=?

+CME ERROR: no network service

I suspect this one might be a hardware issue over what I have seen previously as it will always throw Unknown GPRS Error. I’ll try a few other things on it and see if I can get it to recover (possibly a new SIM)

Additional issues around this particular device:
AT+NEER (undocumented) returns no cell available or internal error.

#7

Could you try to see result of following?
AT+CPIN?
AT+CFUN?
AT+CFUN=1,1

#8

On the troubled device (not the original reported issue here) running the above commands reports:
AT+CPIN?
AT+CPIN?

+CPIN: READY

OK
AT+CFUN?
AT+CFUN?

+CFUN: 1

OK
AT+CFUN=1,1
AT+CFUN=1,1

OK

Calling CGATT=1 after this still results in unspecified GPRS error. I suspect the radio module is somehow damaged in this specific case. Again, the original reported issue is unrelated to this isolated one.

#9

Maybe you can insert the SIM into your mobile phone to see if it works?

#10

I have tried multiple SIMs that do work in other devices. It’s definitely a hardware issue with this specific device. Again, remember, this one device is not related to the bigger issue as originally outlined.

#11

Hi robvice,

I cannot help if a hardware issue. Regarding “AT+COPS=? +CME ERROR: no network service” issue, please try to restore all the NV default value including customer settings by AT+NVRST=2(a reset will happen automatically) to see if it can help. Or try to upgrade FW again.

#12

Hi klin, no luck on the defective device with the NVRST=2 (again this one device is outside the original issue presented here). The original issue is still present on GOOD hardware.

#13

Hi klin,

What is the ETA for the 5.5.26 firmware? We would really like to put this on 100 of our devices and see if things improve.

Thank you

#14

Hi robvice,
Please try the enclosed FW 5.5.26_2. Remove last “.7z” in the file name and unzip the two files.
RHL85xx.5.5.26.0.201905031309.x6250_2.7z.001.7z (3 MB)
RHL85xx.5.5.26.0.201905031309.x6250_2.7z.002.7z (2.6 MB)

#15

Are there preliminary release notes as to what is fixed in this version?

#16

FW 5.5.26 is not officially released yet. So I cannot provide the release notes.
Please check if the 5.5.26_2 can improve or not.

#17

Good progress, we ran our firmware that initially identified the problem and have only had a few minor drops in connectivity (2 or 3 connections and recovered). None of our devices have been offline for the hours/days that the issue really created. This is great!

The next big question, when might we see the 5.5.26 release? We’re looking to update our existing devices and update our manufacturing process to include the new HL firmware.