u-blox
uSockGetHostByName() fails if we use stubs for wifi.
Hello all We are using cell sockets to resolve the address of a host. However, with the current master branch this fails. The reason seems to be in uWifiSockInit() line 474 in u_sock.c. This function is also called when only cell sockets are used. In this case the call fails with error code -5.
If I comment out the line, everything works as before. Is there any other way I can work around this problem?
Hi there! -5 is -U_SOCK_EIO; a quick look at the code suggests that uWifiSockInit() is being called, which does a lock on uShortRangeLock() but uShortRangeInit() has not been called at this point and so the lock fails. I guess that the u_sock code should also call uShortRangeInit() if it is going to call uWifiSockInit(): @antevir?
Yes, it sounds like uShortRangeInit() has not been called. However, this should happen when you call uNetworkInit().
@eeFLis could you maybe share the init code you are using?
Hi
The error also occurs in the socket example provided in ubxlib/example/sockets/.
uShortRangeInit() is not called by uNetworkInit() because we are using wifi stubs.
Ahh.. just saw that in the title now. Unfortunately there are no proper way of excluding wifi at the moment. We are planning to address this in the next quarter: UPCOMING_CHANGES.md. So I am afraid that if you want to remove wifi by mocking you will also need to mock u_wifi_sock.c.
Apologies for this @eeFLis: we had thought the stub mechanism would work originally but it is really not scaleable, hence we are planning a different solution as Andreas describes. Are you able to work around the issue as Andreas suggests until we have a better solution in place?
@RobMeades Yes we can work around it until there is a better solution. Thank you.
Hi Rob is there a way in release 1.0.0 to exclude unused APIs such as wifi ble gnss? I thought it was planned for this version but I can't see any possibility.
Hi again, and apologies: this was something we wanted to get in for this release but re-jigging all the underlying things to introduce the device/network API, which paves the way for doing what you want, took longer than we thought. So the hooks are there, we need to get down and do the implementation now.
In fact, just a few hours ago we had a meeting about next priorities and this was highlighted. We are shooting for October; basically it comes after LARA-R6 support and I2C support, both of which are happening now.
Apologies again: what I might do, as soon as we have something, is push a preview branch of it here so that you can see if it works for you.
Hi Rob
That would be great. this will help us to reduce the memory footprint. Thanks If there is a preview we will test it.
@eeFLis: just an update that this is being worked on but didn't make it into 1.1.0. We will let you know as soon as there is something to try.
Hi Rob
Do you know when we will have something to try? We are slowly running out of memory.
Hi there: unfortunately the guy who was working on this hasn't. That said, as a side-effect of doing the CMUX work, we've ended up creating the bits of code needed to make the jump-tables that are required for this kind of "link-time" separation to work, so I can probably start looking at this myself from the start of next week.
That would suggest probably not this year but, maybe, just maybe...
Apologies again for the extreme delay on this, don't like having issues open for an entire year, though it is not the record breaker :-(.
Hi Rob
Since the lib is growing constantly (which is great), in most cases not all components (gnss,wifi,ble,cell) are needed. herefore it would be useful to have this feature.
already many thanks for your work
Understood: the growth worries me a little actually, it might be that some of the things we are adding even within, for example, cellular, are not of general interest and the code size just becomes an overhead. Anyway, will try to at least allow you to remove the things that you are definitely not interested in.
Had a bit of a revelation yesterday and realised that fixing this problem is a lot easier than I thought. I have pushed a preview branch of the solution here:
https://github.com/u-blox/ubxlib/tree/preview_separation_rmea
On this preview branch you should be able to change the UBXLIB_FEATURES make/CMake variable that you pass to the common ubxlib.mk and ubxlib.cmake files to, for instance, "cell" instead of "cell short_range gnss" and it should automatically stub-out the not-needed calls.
FYI, the preview branch is arranged such that it includes the preview-fix we did for your issue #75. Please let me know if it does what you want.
Also FYI, this is a preview, we've not actually reviewed this change internally yet, though I anticipate no problems. Once we merge the change to master and push it here I will delete the preview branch.
Actually, there's still a bug in that branch, the one you raised here originally, let me fix that and I'll update this issue when I've done it.
We use the STM32 Cube IDE, which does not have cmake integrated. but I think it should be possible to stub-out the not-needed calls in the same way.
Is this only a temporary solution? I thought you mention that the stub mechanism is not really scalable and you are planning another solution?
That's what I had originally thought but it is only not scalable because of having to swap in and out the stub files for the N cases; the revelation I had last night was that each common module which calls down into a ble/cell/gnss/short_range/wifi thing (which is where the cross-linkage occurs) simply has to provide its own stub versions of those calls that are weakly-linked, and that return "not supported" or whatever, then we can leave the stub files always in place and remove the real implementations as we wish, leaving the stub to take over. A nice simple rule: you call it, you stub it, very little to go wrong and easy on the brain.
I assume you're using the full Eclipse system? If you were just using a Makefile project we support that through the ubxlib.mk file but, anyway, all you should need to do is to add all of the stub files that have been introduced in the branch into your Eclipse-based build and then you can leave out all of the ble/gnss/short_range/wifi or whatever it is that you don't want and it should all link and work. I haven't yet been able to run this myself and won't be able to do so for a while so just let me know if I've missed anything.
The other approach, what I was preparing for, was to create interface types: for instance there would be one for things that MQTT needed for services from cell/wifi, but then we'd need to define/create structures of jump-tables and populate them at some point, etc,, all of which [I realised] is unnecessary overhead when weak and the GCC linker marches in to the rescue :-).
Actually, let me push to the preview branch again: I've just changed some of the file names during review and so if you're manually adding them it is better to get that all right. Will comment back here when pushed...
Right, please use this branch: https://github.com/u-blox/ubxlib/tree/preview_separation_use_this_one_rmea
I will delete the other one shortly.
in u_device.c you check for U_ERROR_COMMON_NOT_IMPLEMENTED but stub functions return U_ERROR_COMMON_NOT_SUPPORTED. after this change it works for us. (we use cell only).
Ah, great, thanks for that, we will fix it on the version we merge to master. I will leave this issue open until the final version ends up here.
I think its not releated to this change but if uSockCreate() is the first function called after psm, it returns error code =U_SOCK_ENOBUFS. This because uAtClientUnlock in uCellSockCreate() returns U_ERROR_COMMON_DEVICE_ERROR.
If we call uCellPwrIsAlive() bevor uSockCreate() everything works fine. But as I understand it, this should not be necessary right ?
Interesting: are you able to see what AT sequence causes the AT parser to get upset?
I mean, I guess it is that AT+USOCR is failing in some way; uCellPwrIsAlive() is going to bounce an AT off the module, just to make sure it is there, but you're right, that should make no difference at all. Just out of interest, are you using UART sleep as well as PSM?
EDIT: you're on R5 so you must be, it wouldn't go into "real" PSM otherwise.
It might be interesting to see if you called something like uCellInfoGetManufacturerStr() at that same point, does it fail also, i.e. is this specifically sockets related or is it just that any AT command that does not retry, if called just after return from PSM, fails in this way?
uCellInfoGetManufacturerStr() works at the same point but uCellInfoGetIccidStr() dont.
seems like the problem is only with functions that wait for a specific response uAtClientResponseStart.
In the debug print it seems that then the command is sent before the module is awake.
`AT+CCID U_CELL_INFO: unable to read ICCID.
AT AT
OK ATE0 ATE0
OK AT+CMEE=2
OK AT+UDCONF=1,0
OK ATI9
03.15,A00.01
OK AT&C1
+UUPSMR: 0
OK AT&D0
OK AT&K3
OK AT+UPSV=3
OK AT+UPSMR=1
OK AT+CPSMS?
+CPSMS: 1,,,"01000011","00001000"
OK AT+UMNOPROF?
+UMNOPROF: 90
OK AT+UPSD=0,0,0
OK AT+UPSD=0,100,1
OK AT+UPSDA=0,3
OK
+UUPSDA: 0,"IP" AT+USOCR=17,PORT
+USOCR: 0
OK U_SOCK: socket created, descriptor 2, network handle 0x2000cf88, socket handle 2. U_SOCK: connecting socket to "IP:PORT"... AT+USOCO=0,"IP",PORT
OK U_SOCK: socket with descriptor 2, network handle 0x2000cf88, socket handle 2, is connected to address "IP:PORT".`
Very interesting, thanks for that, there is definitely something going wrong here. Let me just get my head straight on some things:
- is it correct that you have
VINTconnected to the MCU (so you can tell that the module is in deep sleep)? - before the start of the sequence above, the module has entered deep sleep due to 3GPP power saving.
- while in deep sleep you send an AT command to do something, e.g. create a socket; this is the command at the origin of the AT sequence above.
What should happen is that, before sending the AT command, the AT client will call uCellPrivateWakeupCallback() which will call uCellPrivateIsDeepSleepActive() and, if power saving has been agreed with the network and VINT has gone low, deepSleepWakeUp() will be called, which will reconfigure the module: you can see that happening with the ATE0 etc. in your AT log.
But, somehow or other, deepSleepWakeUp() is not returning that the module is in deep sleep. Hmph.
yes we have VINT connected to the MCU. we use uCellPwrGetDeepSleepActive to check whether the module has entered deep sleep. We can also see from the power consumption that the module is in deep sleep.
during the deep sleep the MCU wakes up to transmit some data, for this a UDP socket is opened. this is what you see in the AT sequence.
strangely enough the command order of uCellInfoGetManufacturerStr() is correct.
AT AT
OK ATE0 ATE0
OK AT+CMEE=2
OK AT+UDCONF=1,0
OK ATI9
03.15,A00.01
OK AT&C1
OK AT&D0
+UUPSMR: 0
OK AT&K3
OK AT+UPSV=3
OK AT+UPSMR=1
OK AT+CPSMS?
+CPSMS: 1,,,"01000011","00001000"
OK AT+UMNOPROF?
+UMNOPROF: 90
OK AT+UPSD=0,0,0
OK AT+UPSD=0,100,1
OK AT+UPSDA=0,3
OK
+UUPSDA: 0,"IP" AT+CGMI
u-blox
OK U_CELL_INFO: ID string, length 6 character(s), returned by AT+CGMI is "u-blox". AT+USOCR=17,5684
+USOCR: 0
OK U_SOCK: socket created, descriptor 2, network handle 0x2000cf88, socket handle 2. U_SOCK: connecting socket to "IP:PORT"... AT+USOCO=0,"IP",PORT
OK U_SOCK: socket with descriptor 2, network handle 0x2000cf88, socket handle 2, is connected to address "IP:PORT".