Open tcpipchip opened 3 years ago
@tcpipchip thank you for raising this issue.Please take a look at the following comments:
Could you add some more detail to the description? A good description should be at least 25 words. What Mbed OS version are you using?
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information.
updated! And here is the video https://www.youtube.com/watch?v=PiDtcV3Ugx8 all works fine if include a printf("%s\n","EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE"); in the main() code that blocks my console If didnt include that or...include a text not too big, no works too.
@ARMmbed/team-ublox @ARMmbed/mbed-os-connectivity Please review
Your print is affecting timing (severely) so might have side effects on how the driver works. I'm sorry but I don't understand what the issue is. Is there some original bug report this is a follow-up to?
Hello @paul-szczepanek-arm
Very hard to explain
If the main UART (CONSOLE) is working, the AUX UART (MODEM) not works, looks that freeze during message receive (the ECHO ANSWER of server)
If the main UART (CONSOLE) stop to work (long message sent), the AUX UART (MODEM) works, i can see the ECHO ANSWER of server)
btw, i have to send at begining a long message to UART (CONSOLE), wich BLOCK the UART. Then the AUX UART works very nice!
if at the beginnig i send a short message to UART (CONSOLE), not BLOCK the UART, but the AUX UART not works more only on the ECHO RECEIVE message of server.
Weird
Not sure I understand your problem but maybe your modem isn't ready when you send the message, hence why changing the timing with the print makes it work - maybe a delay is required? What is the command that fails? Is it a command that can fail and can be retried?
AT+USOWR=0,49 TESTANDO ENVIO DE PACOTES!!!!!!!!!!!
Should answer
+UUSORD: 0,49 +USORD: 0,49,"TESTANDO ENVIO DE PACOTES!!!!!!!!!!!"
But only answer if UART CONSOLE FREEZE
AT+USOWR=0,49 TESTANDO ENVIO DE PACOTES!!!!!!!!!!!
no ECHO back :(
it´s exactly whats happens too with PPP example...if no CRASH during the CONSOLE UART....all works fine in UART MODEM
but no worry!
on https://github.com/ARMmbed/mbed-os-example-cellular modem AT command Socket receive
Target(s) affected by this defect ?
NRF52832 (Nina B112)
Toolchain(s) (name and version) displaying this defect ?
Mbed Studio: 1.4.1
What version of Mbed-os are you using (tag or sha) ?
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
Mbed Studio: 1.4.1
How is this defect reproduced ?
I found something very interesting! If you put in UBLOX_AT__celularStack.cpp the following instruction:
printf("%s\n","EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE");
UBLOX_AT_CellularStack::UBLOX_AT_CellularStack(ATHandler &atHandler, int cid, nsapi_ip_stack_t stack_type, AT_CellularDevice &device) :
AT_CellularStack(atHandler, cid, stack_type, device) { // URC handlers for sockets
printf("%s\n","EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE");
_at.set_urc_handler("+UUSORD:", callback(this, &UBLOX_AT_CellularStack::UUSORD_URC)); _at.set_urc_handler("+UUSORF:", callback(this, &UBLOX_AT_CellularStack::UUSORF_URC)); _at.set_urc_handler("+UUSOCL:", callback(this, &UBLOX_AT_CellularStack::UUSOCL_URC)); _at.set_urc_handler("+UUPSDD:", callback(this, &UBLOX_AT_CellularStack::UUPSDD_URC)); }
Blocks my UART (console)...
But....all AT commands sent to MODEM work perfectly now, i can see now the ECHO! See the picture
Can you give some tip about ?
If i remove the printf("%s\n","EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE"); fail![image](https://user-images.githubusercontent.com/11488460/124787894-40dae680-df1f-11eb-9064-81b3c8cf3dcf.png)
By the way, the parameter on printf must be a LONG string :( "EEEEEEEEEEEEEEEEEEEEEEEEEEEE.... and "platform.stdio-buffered-serial": true, to work
Very weird! Some tip ?