search

u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
288 stars 84 forks source link

SARA-R510S keeps CTS line sporadically high if DTR is used for power saving #192

Open eeFLis opened 5 months ago

eeFLis commented 5 months ago

Hi

maybe no ubxlib related problem, but perhaps you have already observed this behavior

If the DTR pin is used for power saving, the SARA R510 s module sporadically holds the CTS line high and no longer releases it. the module is then no longer responsive.

we had the problem several times with the module firmware version 03.15, A00.01. We hoped that this problem would be solved with the current module firmware version 03.30, A00.01, but the problem still occurs, even if it is much less frequent (after hours ).

Have you observed such behavior in your test environment?

RobMeades commented 5 months ago

If you are not using CMUX (which I think is the case) then U_CELL_PRIVATE_DTR_PIN_HYSTERESIS_INTERVAL_MS is not used. If you are using CMUX (which would only be if you are using a GNSS chip connected via or within a cellular module, or you are using PPP) then it probably still doesn't matter but set it to 50 ms to be safe.

eeFLis commented 5 months ago

have checked it in the saleae trace should be ok now.

eeFLis commented 5 months ago

The error has just occurred again. Do you need the trace?

RobMeades commented 5 months ago

You're getting good at this :-|. The trace might be useful, if possible.

eeFLis commented 5 months ago

:-) Would be happier if the error disappeared.

Here the recording capture U_CELL_PRIVATE_DTR_PIN_HYSTERESIS_INTERVAL_MS 50ms -2.zip

eeFLis commented 5 months ago

Hi @RobMeades Is there any news on this topic?

RobMeades commented 5 months ago

I was wondering that myself: apparently the internal expert was side-tracked onto something else, they will get back to it today.

RobMeades commented 5 months ago

...but now they've had a high priority interrupt onto something else, will update you when I know something...

RobMeades commented 4 months ago

FYI, the internal expert is now back on this, investigating...

eeFLis commented 4 months ago

Great, thanks for the information

RobMeades commented 4 months ago

Probably not good news but, FYI, our internal SW expert has now deferred to our internal HW expert: it seems that, on SARA-R5, when DTR is used for power saving control, there is a 3ish ms window, around the time the module is going into sleep, where pulling DTR low causes the module to get stuck, eventually resulting in a watchdog timer going off internally.

He has tried various SW workaround but so far has found nothing which can be guaranteed to avoid this window. Here's hoping the internal HW expert can find something we can use.

eeFLis commented 4 months ago

The good thing is that the cause of the problem could be identified. Thank you for all the great support, if there is anything you want to test, please let me know.

eeFLis commented 3 months ago

Hi @RobMeades Do you have any news from the HW expert on this?

RobMeades commented 3 months ago

Sorry for the delay in this: I'm told the HW team are currently discussing it, will get back to you when they have something to say.

eeFLis commented 3 weeks ago

Hi @RobMeades Do you know if there is the same restriction with the sara SARA-R52 series or could it be a solution to switch to this?

RobMeades commented 3 weeks ago

Hi @eeFLis: that's an excellent question. I've been prodding the HW people periodically and the last thing they said was that they would arrange a meeting with me to discuss the right way forward. I've just asked them again and added this question to the agenda.

I can only apologize for the extreme delay here, will try to increase the pressure.

eeFLis commented 3 weeks ago

Many thanks for your help. We will produce another series of prototypes thats why I asked about the SARA-R52 series.

RobMeades commented 3 weeks ago

Just had a call with one of the project managers on the HW side and some of the module SW team. Not a huge update but guess is that SARA-R52 won't make a difference to the problem, since the problem appears to be on the baseband side and that is not changed in SARA-R52.

One thing that one of the SW guys has proposed is that maybe an external HW circuit could provide a fix: something which would gate DTR according to the state of CTS and delay the onwards transmission of DTR towards the module, a kind of HW workaround, hiding the problem from the module. It would likely require something like this:

https://www.digikey.co.uk/en/products/detail/onsemi/MC74HC02ADR2G-Q/23329595

Of course, we have not actually tried this ourselves yet, just wondering if it is something that you could do within the constraints of your product or not?

eeFLis commented 3 weeks ago

To be honest I don't understand how this should help, since the error occurs without the level of DTR altering. https://github.com/u-blox/ubxlib/issues/192#issuecomment-1931950069 Is clear what exactly is causing the problem?

RobMeades commented 3 weeks ago

Hmmm, I had forgotten that case; the expert here made the problem state occur by toggling DTR constantly. When he did this he found a window in which the module would fail to return from sleep (indicated by CTS staying high). The implication of your trace is that something about being in "sleep if DTR lets you" mode can cause the problem, irrespective of the state of DTR, though I guess that would be more difficult to reproduce reliably.

I will add this specific data point to the internal ticket.

RobMeades commented 6 days ago

[lack of an] update: another internal meeting, no significant progress to report I'm afraid, am persisting...