Can you switch the codes from ESP-IDF to ESP32 libraries in Arduino IDE?

[Paryavi]

Hi There,

Thank you so much for your codes for ESP32 MCU in ESP-IDF, I have lots of ESP camera boards and a Hologram Nova that has Sara-R410 and I want to connect ESP32 to it. But the problem is all of my previous application codings are in Arduino IDE as most ESP32 codes are written in Arduino IDE! So would you please modify your code so that we be able to use ubxlib library in Arduino IDE platform instead of IDF, like what Sparkfun people did?

Thank you so much!

[Paryavi]

Hi Rob, Thank you!

My Yesterday Updates: As you know I was working with Arduino IDE, but yesterday I installed arduino cli, and it was not recognizing Adafruit ESP feather, but I got its --fqbn from list of boards in cli and I changed the directory to the sockets.ino; cd C:\Users\myUser\Documents\Arduino\libraries\ubxlib\examples\sockets

Then for compile; arduino-cli compile --build-property "compiler.cpp.extra_flags=\"-DU_CELL_PWR_ON_PIN_INVERTED\"" --fqbn esp32:esp32:featheresp32 sockets

Then right after that for upload I used; arduino-cli upload -p COM5 --fqbn esp32:esp32:featheresp32 sockets OR arduino-cli upload --build-property "compiler.cpp.extra_flags=\"-DU_CELL_PWR_ON_PIN_INVERTED\"" --fqbn esp32:esp32:featheresp32 sockets

I was able to upload it to ESP feather but was getting error handle -5 again.

Also, I watched the Harvard CS50 C Youtube video to understand make file and compiling details(I took an embedded C from Udemy to be watched...)... I cant use the make command on windows yet, not sure I need it because Arduino cli already compiles?

I was able to download the new commit, will check it on Arduino cli now.

Thanks, MoZen

[RobMeades]

To get the new files, git pull is what you want.

On the compilation mechanism, use whatever it is your platform uses, so for ESP32 you'd use CMake, for Arduino you use Arduino's home grown mechanism. arduino-cli is the most recent flavour of the Arduino thing and seems relatively usable. If you had a platform that used make then you'd use make but Arduino doesn't so you don't, if you see what I mean; no point in causing extra pain (which make certainly will on Windows).

Do make sure, though, that you do a clean build; above you say "I compiled the sockets.ino" and then "for compile", which makes it look as though you may have already compiled the files once before you add the compilation flag in the second step.

Putting it another way: you want to start off with no build products, so delete any build directory etc. and then do one arduino-cli compilation of the whole lot, along the lines of:

arduino-cli compile --fqbn esp32:esp32:featheresp32 --clean -v --build-property compiler.c.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED" --build-property compiler.cpp.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED" sockets.ino

This has the -v verbose flag so that you can see exactly how each file is being compiled, has --clean for good measure and adds the compile flags both for .c and .cpp 'cos I'm not sure whether an .ino file is considered to be C or C++.

On the powering on and off thing, it might work from a button, everything depends on timing and which way up the edge is: mashing a button with a finger can do things (bounces, multiple tries, etc.) which no machine-driven pin would do.

[RobMeades]

To be quite sure that the compilation flag is being passed through to the compilation process, edit u_cell.h to add a #error as below:

#ifndef U_CELL_ENABLE_POWER_PIN_INVERTED
# define U_CELL_ENABLE_POWER_PIN_ON_STATE 1
#else
# error U_CELL_ENABLE_POWER_PIN_INVERTED is most definitely defined!
# define U_CELL_ENABLE_POWER_PIN_ON_STATE 0
#endif

It the compilation processes fails with that #error then you know the compilation flag is being used.

[Paryavi]

above you say "I compiled the sockets.ino" and then "for compile" Sorry I meant; I changed the directory to the sockets.ino and then for compile... I modified my comment. Thank You, I will implement the changes and see what happens!

[Paryavi]

Aloha Rob, Ok, looks like we have some progress iwth AT commands. First, I connected pin 32 of ESP feather to PWR NOT in my shared Eagle image(cell enable power) so pin 32 of ESP is now connected to Gate of the PMOS which previously I was connecting the Gate to ground to provide 3.3 volts constantly) and modified u-cfg-app-platform specific;

define U_CFG_APP_PIN_CELL_ENABLE_POWER 32

And like before I have;

define U_CFG_APP_PIN_CELL_PWR_ON 14

define U_CFG_APP_PIN_CELL_TXD 17

define U_CFG_APP_PIN_CELL_RXD 16

It is interesting that whenever the following AT commands are sent to the board, the Red LED is OFF, ReD LED in our board shows if 3V3 is provided for the board(when PWR NOT is Zero), and as you know previously I would physically connect the gate of P-MOS to ground to have 3V3 provided for Sara VCC pin and hence having RED LED ON constantly, now I connected it to pin 32 of ESP and red LED is OFF most of the time

In Arduino IDE serial monitor I have;

U_CELL: initialising with enable power pin 32 (0x20) (where 1 is on), PWR_ON pin 14 (0x0e) (and is toggled from 0 to 1) and VInt pin not connected. AT AT AT AT AT U_CELL_PWR: powering on. [ff][ff][ff][ff][fb][ff][fb][ff][ff][df][fb][ff][fb][ff][fb][fb][ff][ff][fb][ff][ff][ff][ff][ff][ff][df][ff][fb][ff][ff][fb][ff][fe][ff][ff][ff][ff][ff][fb][ff][df][fb][df][7f][ff][ff][ff][fb][ff][fd][df][e7][ff][7f][de][ff][df][bf][ff][ff][fd][df][fd][bf][fd][dd][ff][f7][eb][db][fe][dd][fb][ff][dc][ea][ff][ba][7f][f3][99][f8][df]}[d6][ba][01]p[d8][b8][1f][00][97]R[a5]=[92]<'[00]$[00][00]Dd[92][88][ff][db]bA[84][09]H[02][00][84]HD[04][98][01][00]"[00]A"[00] [90]A [09][00][08][00][88][04][00][04][00][00][01][04][90][01][00][80][08][04][00] [00][00][01][04][01][00][00][00][00][08][04][08][04]@[00][00][05][00][00][10][00][00][00][00][00][00][00][08][00][00][00][00][00][00][00][00][00][00][08][00][00][04][00][00][00][00][00][00]@[00][00][00][00][00][00][00][00][00][01][01][00][00][00][01][00][00][00][08][00]@[08][00][00][00]@[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][04][90][00][00][00]$[90][00][00][00][00][00][00][00][00]$[90][00][00][00]$[00][00][00][01][00][08][00]H[00][00][00][00][00][08][00][00][01][04][00]@[00][00][00][00][04][00][00][00] [00] [00][00][00][00][00][00][00][00][00][01][00][00][00][00][00][04][00][00][00][00][00][00][01][00][00][00][00][00][00][04][00][00][00][01][00][00][00][00][00][00][00][00] [00][a0][80][01][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]@[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][01][00][08][00][00][00][00][04][00][00][00][00][80][10][00][00][00][00][00][00][00][00][03][00][00][00][01][00][00][00][00][00]$[00][00][01][00]@[00][00][00][00][00][00][00][00][00][00][00][00][00][01][00] [00][00][00][00][00][01][00][00][00]@[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][08][00][00][00][00][00][00][00][00][00][00][00][04][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00] [00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][80][02][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]AT AT AT AT AT

AT AT AT [ff][fb][ff]{[ff][fb][ff][f3]O[1f][83]@[00][07][02][00][00][00][00][00][00][01][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]AT AT AT AT AT AT commands do not stop in the serial monitor...

Also in order to have compile-upload consecutively in Arduino CLI, I just added -u for upload and it needs port number too; -u -p COM5

arduino-cli compile --fqbn esp32:esp32:featheresp32 --clean -v -u -p COM5 --build-property compiler.c.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED" --build-property compiler.cpp.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED" sockets.ino

But adding the error where you mentioned did not stop compiling in Arduino CLI. So I am not sure if the toggling flag is working or not.

Btw, I can't compile it from Arduino IDE, which is not that important;

In file included from C:\Users\myUser\Documents\Arduino\libraries\ubxlib\src\u_at_client.c:43: C:\Users\myUser\Documents\Arduino\libraries\ubxlib\src\u_at_client.c: In function 'uAtClientInit': C:\Users\myUser\Documents\Arduino\libraries\ubxlib\src\u_cfg_os_platform_specific.h:97:36: error: 'CONFIG_ESP32_PTHREAD_TASK_PRIO_DEFAULT' undeclared (first use in this function)

define U_CFG_OS_APP_TASK_PRIORITY CONFIG_ESP32_PTHREAD_TASK_PRIO_DEFAULT

Thanks

[RobMeades]

Definitely heading in the right direction now. A few things:

GPIO 32 of the ESP32 chip is, unfortunately, not an entirely normal GPIO, it has a dual purpose to act as a 32 kHz crystal input on the RTC GPIO bus. So it will come up at boot as an RTC GPIO and an input, not a normal GPIO and an output, which is what you want.

So somewhere in your code, before any ubxlib stuff (e.g. at the very start of setup()), I think you will need to call something like:

rtc_gpio_deinit(U_CFG_APP_PIN_CELL_ENABLE_POWER);

...to make that pin a normal GPIO; the ubxlib code will be able to handle it from there.

On the #defines, I think passing in U_CELL_PWR_ON_PIN_INVERTED is working because the debug print from U_CELL says:

U_CELL: initialising with enable power pin 32 (0x20) (where 1 is on), PWR_ON pin 14 (0x0e) (and is toggled from 0 to 1) and VInt pin not connected.

For the PWR_ON pin it says is toggled from 0 to 1, which is the opposite of what it would usually say. I think you might have edited the wrong u_cell.h when adding the #error to check this out: remember that, because Arduino insists on files being in a specific directory structure, our u_arduino.py script copies the files into that required directory structure; you either need to edit the copied file or you can edit the original file and run the u_arduino.py script again to copy the edited version into place.

Of course, you have not passed U_CELL_ENABLE_POWER_PIN_INVERTED into the build, so that would still be the wrong way up, even if you had added rtc_gpio_deinit() in the start of your application.

Just to show you how it should work, I have gone through all the build steps from scratch myself and a text file is attached which shows both what I did and the full output from the Arduino tools; search the text file for lines which commence >>### containing my comments. You can see the build fail because it hits the #error and then, when I remove the #error, it builds to completion.

esp32_build_output_rob.txt

[Paryavi]

Thanks, Rob, you are right the error works as I followed the temp folder ubxlib copy;

I also connected V_int "inverted" to pin 18 of ESP!

Also the build works with cpp not c, which is shorter in text now;

arduino-cli compile --fqbn esp32:esp32:featheresp32 --clean -v -u -p COM5 --libraries . --build-property compiler.cpp.extra_flags="-DU_CELL_VINT_PIN_INVERTED -DU_CELL_ENABLE_POWR_PIN_INVERTED -DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_R410M_02B -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19 -DU_CFG_APP_PIN_CELL_VINT=18 -DU_CFG_APP_PIN_CELL_PWR_ON=14 -DU_CFG_APP_PIN_CELL_TXD=17 -DU_CFG_APP_PIN_CELL_RXD=16" ubxlib\examples\sockets\sockets.ino

If you like I can send our board schematic PDF to your email provided on meades.org or to your LinkedIn!

Also, Right inside setup()), after its curly brace, I added: rtc_gpio_deinit(U_CFG_APP_PIN_CELL_ENABLE_POWER); But when I add it in sockets.ino file, it does not compile even with cli, so I removed that and just changed pin from 32 to Pin 19 and it compiles with our arduino-cli code!

Arduino serial result; U_CELL: initialising with enable power pin 19 (0x13) (where 1 is on), PWR_ON pin 14 (0x0e) (and is toggled from 1 to 0) and VInt pin 18 (0x12) (and is 1 when module is on). U_CELL_PWR: powering on, module is already on. [00]ATE0 AT AT AT AT ATE0 U_CELL_PWR: powering on. [fb][fe][ff][ff][ff][ff][fb][fb][fb][ff][ff][ff][ff][ff][ff][ff][ff][ff][fb][ff][ff][ff][fb][ff][ff][ff][ff][ff][fe][ff][ff][ff][ff][ff][f7] Unable to add network, error -7!

More details on Serial; arduino_serial_Mohsen.txt

Thanks, MoZen

[RobMeades]

Hmm, OK, you say "the build works with cpp not c, which is shorter in text now", but it would be really surprising if that were the case; u_cell.c, u_cell_pwr.c etc. should be treated as .c files and not .cpp files. It looks to me as though the flags are being applied to the .ino file (because the pin numbers are coming out correct and they take effect in the .ino file), which I guess is being turned into a .cpp file, but I suspect they are NOT being applied to any of the .c files, which is where the inversion takes effect; the U_CELL print-out has VInt pin 18 (0x12) (and is 1 when module is on), i.e. VINT has not been inverted, the code still thinks 1 means "on".

I note that you are no longer inverting the PWR_ON pin. Is that intentional? Also note a spelling mistake above U_CELL_ENABLE_POWR_PIN_INVERTED: should be U_CELL_ENABLE_POWER_PIN_INVERTED (missing the E in POWER).

Assuming you did still intend to invert all three pins then I think if you try:

arduino-cli compile --fqbn esp32:esp32:featheresp32 --clean -v -u -p COM5 --libraries . --build-property compiler.cpp.extra_flags="-DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_R410M_02B -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19 -DU_CFG_APP_PIN_CELL_VINT=18 -DU_CFG_APP_PIN_CELL_PWR_ON=14 -DU_CFG_APP_PIN_CELL_TXD=17 -DU_CFG_APP_PIN_CELL_RXD=16" --build-property compiler.c.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED -DU_CELL_ENABLE_POWER_PIN_INVERTED -DU_CELL_VINT_PIN_INVERTED" ubxlib\examples\sockets\sockets.ino

...there's a chance things will start working. Note that this applies some flags only to the .ino file and some flags only to the .c files: I would normally apply all the flags to all files, basically pasting them all in twice, since that is less likely to lead to mistakes; I've only done the above to save you typing and because I know which kinds of files each flag has to be applied to.

[Paryavi]

I guess our Reset Pin is inverted too(when applying power to the gate of Q2 then it will provide zero volts to Sara pin 18; Pin Reset_N, that is the only thing I did not connect yet from feather to Sara module! All our transistors are N-MOS, only Q5, the Cell_enable_power one is P-MOS.

Thanks for correcting my error on the build side, also on typo since in some places like in socket.ino U_CFG_APP_PIN_CELL_PWR_ON was used I used it as PWR. Yes, I tried to tweak the pins inverting and not inverting them to see if it will work! but it was probably not a good idea, haha!

Using your code, and with no deinitiaizing pins in sockets.ino code as before, Now we have; U_CELL: initialising with enable power pin 19 (0x13) (where 0 is on), PWR_ON pin 14 (0x0e) (and is toggled from 0 to 1) and VInt pin 18 (0x12) (and is 0 when module is on). U_CELL_PWR: powering on, the module is already on. [00][e0]ATE0 [fb][ff][ff][ff][ff][ff][ff][ff][ff][fb][ff][fb][ff][fb][ff][ff][ff][ff][df][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][7f][ff][ff][ff][ff][ff][bf][ff][f7][ff][ff][ff][ff][ff][fb][ff][ff][fb][ff][fb][fb][ff][fb][df][7f][f9][fb][fb][ff][ff][ff][ff][fb][ff]7[fb][ff][ff][ff][df][ff][ff][7f][fa][ff][ff][ff][ff][fb][df][de][df]w[fb][ff][df][ff][ff][ff][df][fb][af][bf][f7][ff][fb][be][ff][ff][ff][ff][ff][ff][7f]/[ff][fe][ff][ef][ff][fd][b3][eb][7f][ff][ff][ef][fe][fb];[fe]][dd][b6][bb][bd]?[be],[ff][8f]?[fe]~[8a][f5][df]Y[da][b7][d4][d2][cc][0c][f2]<[db][9b][1e][14][HDfW[14]0[d5][f0][08]PE$[a3][1f][00][c4][10]C[07][aa][0c]7[fa][80]&[00][00]![95] [12][00][12]P[81][00]!D [01][00][12]@[00]$[04][80][00][01][00][05][00][05][92]A"[10] [00][02][08][0c][00][01][90][80][00][00][11][01] [00][00][00][00]P[00][00][05][04][10][00][10][00]@[00][08][00][00]%[00][00][04][00][00][00][00][00][00][04][00]a[00][00][00][02][08][00][00]@[00][00][00][00][00][00][00][10][00][00][00][01][00][00][00][01][00][10][00][00][08][00][02][08][00]@[00][08][00]X[00][00]A[00][00]"[00][00][00][00][00][00][02][00][00][00][08]@[00][00][00][00][00] [00]@[00][00]H[00][00][00][00][00][00][00][00][00][02][00][00][00][00][00][00][82]@[00][00][00][00][00][09][00][00][00][00][00][00][00][00][00][00][00][00][00]AT AT Unable to add network, error -7! Network is not available! 1 Tests 1 Failures 0 Ignored

Is it my board design problem? Is the board working with the serial reports? Should I solder a new board? I think I probably should use the oscilloscope to see if the Uart transmission is working!

Also Header Pins; Feather Pin 14 is connected to Sara-module Pin Start which goes to the gate of Power_On pin with Q6 transistor. Feather Pin 18 is connected to Sara-module Pin SARA_R4_ON Not which is the inverse of V_INT. Feather Pin 19 is connected to Sara-module Pin PWR Not which is the inverse of Power ON Enable; when it is connected to GND, Gate of Q5 transistor which is a PMOS will conduct 3 volts from feather to Sara. Feather Pin RX and TX have also connected accordingly.

Thanks

[RobMeades]

I think I probably should use the oscilloscope to see if the Uart transmission is working!

Yes, I think that's the next step.

As far as I can see, assuming that the lines from the MCU to the module for enable power, PWR_ON, and VINT are all inverting, then the code is being built correctly for that (from the U_CELL print), which only leaves the level shifting of the UART. A storage scope or Saleae probe, something that can show you the dynamic behaviour over time, is what you need to check that the UART data is good, both at the module in the TXD direction and at the MCU in the RXD direction.

The pattern of received UART data being printed out above would suggest that something slowly slewing from 0xff to 0 rather than being proper crisp received bytes.

[Paryavi]

I found a Tektronix TDS2012 Digital storage scope in our lab, and it looks like the 115200 baud rate is equal to 86 microseconds, so I tune the sec/dv on the scope to be around 100 microseconds, but I have not seen anything interesting to or from RX and TX so far, just a DC shift when it sends AT commands, not sure whats wrong with it...

The pattern of received UART data being printed out above would suggest that something slowly slewing from 0xff to 0 rather than being proper crisp received bytes. Do you have a successful UART reference for sent and received through RXD and TXD? Since you said you use Sparkfun level shifter do you think our design for level shifting will work? Do you add capacitors in the way? It looks like there should be a 100 nF capacitor on V_int on Fig 45 of the integration manual, I will add those to see if it helps... Thanks

[RobMeades]

For the TXD/RXD UART stuff it is not something I've ever had to worry about, I usually just connect-up via the Sparkfun bidirectional level shifters and that works for me (with VH connected to the MCU's 3.3V and VL connected to the module's VINT).

Here are a couple of screen-shots I have taken of a Saleae probe output in the past: one of the power on process and another of just AT being sent to the module. In the images CP_ON is another name for PWR_ON; all traces were taken on the module-side of the level shifters.

[RobMeades]

FYI, you see RXD activity in the first image above before any TXD activity only because these traces were taken with a SARA-R5 module that had a development build on it which spits out a lot of identification information at power-on. Normally you wouldn't see RXD activity until after the TXD activity unless a greeting message had been set in the module, i.e. the bits in red below would not appear.

[Paryavi]

In the screenshots, you have 1.8 volts for V_int and since we have populated the V-int a 3rd header(where I just added a 100 nF=0.1 uF capacitor between it and the ground), currently I do not see any voltage on it!; when AT commands are sent in terminal or after it gets -7 error, so I might try connecting cell enable power to ground again to see how it might change the situation!

[RobMeades]

Yes: if the module is not driving its VINT pin to 1.8V then the module is off.

In the AT print-out you included above it says U_CELL_PWR: powering on, the module is already on, which is happening since you have defined U_CELL_VINT_PIN_INVERTED and you have connected the module's VINT to MCU pin 18 via an inverter; the MCU is measuring that pin as 0 which means it must be being driven high (1V8) by the module. At least, that was apparently the case then.

[Paryavi]

Hi Rob,

We just bought the GPS version of the cellular modules as the backlog is over on some vendors, and we will solder a new board with a better regulator design, we might buy Salea probe, I was wondering if logic 8 is enough compared to logic 8 pro. Since u-blox UART uses a 115,200 baud rate, do you think it will work with logic 8? The sample rate is 100 Mega samples/ sec, vs 8 pro which is 500 MS/s. (I suspect since 115,200 is less than 1 Mega samples per second, so logic 8 might work).

Thanks, Mohsen

[RobMeades]

Hi Mohsen: any Saleae probe will work very well on any normal UART, no problem. In my view it is an indispensable tool for the price: I bought one for myself after using one at work.

[Paryavi]

Hi Rob,

Wassup?

We recently soldered a new board having both ESP MCU and SaraModule, MCU works fine so I loaded ublox code on it and we have connected GPIO 19 of it to CFG_APP_PIN_CELL_ENABLE_POWER=19 using the same Q5 PMOS so when GPIO 19 is zero volts, PMOS Source to drain conduct and Sara module is energized; Q5 Image: #29 (comment)

I guess the inverting of cell enable power is not working properly; When I reset the MCU, for a while, GPIO 19 is zero so Sara module gets 3.3V but after a while GPIO 19 switches to 3.3Vs, hence no power to Sara module, and when I leave it for a long time, I see the Gate is zero again hence 3.3V is provided to Sara module. Any reason why the code does that? Also, the board does not provide 1.8V voltage as an internal Pullup, I guess we need to solder another board...

I use the dev module for our MCU in arduino-cli fqbn config (ESP32_WROOM-32UE (has UFL antenna), so I set its esp32 fqbn simply as esp32; esp32:esp32:esp32

arduino-cli compile --fqbn esp32:esp32:esp32 --clean -v -u -p COM3 --libraries . --build-property compiler.c.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED -DU_CELL_ENABLE_POWR_PIN_INVERTED -DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_R410M_02B -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19 -DU_CFG_APP_PIN_CELL_PWR_ON=0 -DU_CFG_APP_PIN_CELL_RESET=2 -DU_CFG_APP_PIN_CELL_TXD=1 -DU_CFG_APP_PIN_CELL_RXD=3" --build-property compiler.cpp.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED -DU_CELL_ENABLE_POWR_PIN_INVERTED -DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_R410M_02B -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19 -DU_CFG_APP_PIN_CELL_PWR_ON=0 -DU_CFG_APP_PIN_CELL_RESET=2 -DU_CFG_APP_PIN_CELL_TXD=1 -DU_CFG_APP_PIN_CELL_RXD=3" ubxlib\examples\sockets\sockets.ino

I have attached the modified library; u_cfg_app_platform_specific.txt

Thanks, Mohsen

[RobMeades]

Hi there: I'm not sure what exactly the application code is that you are running. Is it just our default "runner" example? In which case that will run the examples and many 10's of test-cases and it may power the module on at the start of each example/test-case and off at the end of each example/test-case, that is to be expected.

On the "enable power" pin inversion, if what you've pasted above is exactly what you are using then I think you have a spelling mistake: it is U_CELL_ENABLE_POWER_PIN_INVERTED rather than U_CELL_ENABLE_POWR_PIN_INVERTED (i.e. the 'E' is missing in the flags you've given to the compiler).

I'm not sure what you mean by "the board does not provide 1.8V voltage as an internal Pullup": the module itself provides 1.8V output for level converters and the like (the VInt pin), so you shouldn't need your own 1.8V supply, or did you mean something else?

[Paryavi]

I am running socket.ino mentioned at the end of the arduino-cli command I shared; ubxlib\examples\sockets\sockets.ino The only thing I modified in .ino file is adding "hologram" here; "hologram", / APN: NULL to accept default. If using a Thingstream SIM enter "tsiot" here / I did not even provide the U_CFG_TEST_CELL_MODULE_TYPE U_CELL as I am defining it in cli. "The board does not provide 1.8V voltage as an internal Pullup" Sorry, I meant the hologram module does not turn on! "The 'E' is missing"; Oh, OK I will modify and upload it shortly. I will upload to it with U_CELL_ENABLE_POWER_PIN_INVERTED and see what happens...

Thanks

[RobMeades]

Ah, yes, if you are running the sockets example then that will power the module on at the start and off at the end, so that is fine, though if you have an inverter in the line and the flag passed to the CLI was misspelled the code will be powering the module off at the start and on at the end!

[Paryavi]

Thanks, I see, now it is fixed, I have stable 3.3 Volts on Drain of Q5, however looking at Arduino Serial Monitor, It is just writing ATATAT... I changed that APN from "hologram" to NULL still showing ATATAT on the monitor. Also on SARA pin 4 (V_int where we connected it to a resistor head) I do not see 1.8V! Which tells me Sara is OFF. Btw, we bought the Saleae Logic 8 Probe, what do you use to connect its wires to let's say a few SMD resistor/transistor contacts?

[Paryavi]

Oh, we have inversion on RESET_N pin too!; https://github.com/u-blox/ubxlib/issues/29#issuecomment-1001098138 I guess this is the last inversion trouble, I think we need to add that to u_cell.h too, right?

Thanks, Mohsen

[RobMeades]

If RESET_N is connected but has to be inverted to work then that may be why SARA-R5 is off. That is already provided-for in the code, you just need to add U_CELL_RESET_PIN_INVERTED to your list of flags passed to the compiler.

The Saleae probe comes with a load of very capable tiny connecting clips, you can usually just attach them to the ends of SMD resistors/transistor contacts or, if you prefer, solder short bits of wire to the same points and connect the clips to those wires for something a bit more stable. I suggest you connect probes to PWR_ON (as close to the module as possible), RESET_N (as close to the module as possible), VINT (as close to the module as possible), TXD (as close to the module as possible), RXD (as close to the MCU as possible, since it is an input to the MCU), RTS (as close to the module as possible) and CTS (as close to the MCU as possible, since it is an input to the MCU). You can tell the Saleae probe SW to run its serial analyzer @ 115200 on the TXD line and on the RXD line, and to display the values it sees as both hex and ASCII. Then we can see what is happening.

[RobMeades]

One more thing: for pins where you have set the value you desire correctly in the u_cfg_app_platform_specific.h you don't also need to pass that flag on the compiler command-line; the compiler command-line is only for defining flags that are not set anywhere in the code or a header file or for overriding the values of flags that are already set in the code or a header file.

[Paryavi]

Thanks, Rob, I've added Reset inversion flags to compiler.c and cpp; -DU_CELL_RESET_PIN_INVERTED I will work with Salea Probe next week! Cheers and have a great weekend!

[Paryavi]

Thanks, Rob,

• I have tested the Saleae probe with my scope signal generator, it works! Saleae 8 did not come with connection clips, it has the harness wires though, So I will solder instead.

• For the PCB, we connected RTS and DTR to the ground, and we did not populate the connection for Sara-R4 modules' CTS, DSR, DCD, and VINT to the MCU.

Best Regards

[RobMeades]

Oh, strange, my Saleae 8 probe came with those clips, they must have changed the package of stuff they provide.

[Paryavi]

Oh, actually, I did not know I can remove the 16 clippers from the package! I thought these two extra black boxes are clamps for holding the harness wires! Also, the startup guide does not talk about it assuming everyone is smart, haha! https://support.saleae.com/getting-started/setup

[RobMeades]

Oooo, weird: mine came in a little plastic bag, which is a tad more obvious!

[Paryavi]

Hi Rob,

I hope all is well and thanks for inspiring me to search for and find the Saleae clips! My goal is to have Module Power_ON(looking at 1.6.1 on integration Manual).

I set Saleae to record when it sees a rising age trigger on GPIO0_LTE_START MCU signal applied to the Gate of an NMOS that when is high it will conduct hence provides Low_level on PWR_ON pin(all transistors are NMOS). Only the cell_enable_power signal goes to a PMOS and it will be active when the gate is Zero volts, in that case, it will conduct 3.3V to VCC pin.

I am following your suggestion for having RXD as close to the module as possible but for now, I was curious to see what MCU is sending on the Gates. My question is, I do not understand why U_cell_enable_power(channel zero) toggles! is it because I pressed the Reset button? I think MCU should always provide zero volts on this pin(GPIO19 of MCU which is LTE_START_NOT), similar to Fig.9 of the manual PDF where there is a stable VCC and Power_ON signal toggle to a LOW_Pulse to turn the module ON. In Channel D0 we see Low on both ends of the signal; which provides a stable Low voltage on the gate of PMOS which is good which keeps providing VCC to the module, but channel D0 shows that, at the crucial important time when Power_ON is Low_Level, we see Gate of PMOS jumps to High so actually in that toggle time, the PMOS transistor is OFF, so module does not get any VCC during that time. and UBLOX RXD when it does not receive VCC is sending a Pulse on D4! Our flags are: U_CELL_ENABLE_POWER_PIN_INVERTED -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19

Thanks, Mohsen

[Paryavi]

Since I assume the previous message signals were probably when I hit our reset button on the board, now I just connected the Lipo battery to the board and looked for trigger on Power_ON without pressing any button, it resulted in the following signals; Also, like previous message, I have connected Ground of Saleae to the ground of the HDMI programmer (I use it to load CLI code from PC) and D3 signal which goes to GPIO3/RX MCU(comes from RXD from level shifter) is connected to HDMI programmer RX pin, that is probably why we see a high signal there(I guess I should detach signals from HDMI for now!).

[RobMeades]

I think we need to zoom out a little here: there is nothing in the ubxlib code that operates on the micro-second timeframe. The RTOS tick on Arduino is 1 ms, nothing software-driven is going to happen faster than that, and very likely 10 times slower than that.

For instance, for the UART data lines, running at 115,200 and driven by the UART HW block (not SW), one bit is 8 us, one byte is 80 us (1 start bit, 8 data bits, 1 stop bit), so we need to be looking here at many 100's of ms to see what's going on in SW terms. Anything less than that is HW which I can't really be of much help with!

[RobMeades]

Can you attach a probe to the TXD line as well as the RXD line (TXD from the MCU is what you will see before anything else), in the Saleae PC SW attach a serial analyzer to both of the data lines displaying both ASCII and hex (@115200), then do another trace with a timespan of 15 seconds (yes, I do mean seconds!) from power-on and post the fully zoomed-out view first?

[Paryavi]

Aloha Rob, I have two 15 seconds traces; When everything is Off and I insert the Lipo battery to energize the MCU. Also when Lipo is there and I hit the Reset button connected to EN of MCU.

1. Inserting Lipo:
   • D0 channel: On second 6.5: GPIO19 connected to the gate of PMOS goes Low, hence 3.3V goes to SARA VCC pin.
   • D1 shows: at 6.7 sec, MCU GPIO0 applies high voltage to NMOS Q6 Gate, so SARA Power_ON pin should see toggle from 1 to zero (If there was 1.8V pull-up internal there).
   • D6: MCU TX output(AT command signals?)

2. Lipo was connected so MCU is ON, I started recording with Saleae, then I hit the Reset button on the board; kinda same thing happens;
   

I use level shifter transistors in our design to shift 3.3 to 1.8V (same as Sparkfun level shifter you use; https://www.sparkfun.com/products/12009). Our Level_shifter Gates are energized with V_int:1.8V, I guess since I do not have 1.8V when measuring V_int signal with a multimeter, TX handshake from MCU can not be converted to 1.8V equivalent and reach TXD on SARA (level shifter transistors are OFF as their Gate is connected to V_int). Thanks

[RobMeades]

Great, so those traces all look sensible: the Enable Power line is being brought up, the TXD line is the MCU sending "AT" to see if the module is awake, the PWR_ON line is being toggled by the MCU to power the module on and then to power it off again at the end when it fails to respond.

Can we now add two more probes: one connected to the 3V3 power supply pin of the module and another connected to the V_INT output from the module, both as near to the module as possible, and take another trace? Let's make it 10 seconds this time.

[Paryavi]

Thanks for interpreting the results, before adding more probes, with your explanation I might know what is wrong; Enable Power is not inverted here;

At second 2: You say; the Enable Power line is being brought up; Actually, As I mentioned we only have one PMOS transistor in our design, Q5 (and on D0 Saleae we are looking at its Gate! signal coming from MCU GPIO19); https://github.com/u-blox/ubxlib/issues/29#issuecomment-1040801905 I know PMOS looks different, in conventional NMOS, as you know, when we apply High on Gate, it will switch(source to drain), in PMOS it is the opposite, when we have Low on Gate, it will switch(here in Eagle schematic, when it sees Low on its gate, it will switch 3.3V to VDD which is Sara VCC). So in order to Enable power to SARA, we need to have the opposite waveform. right?

I think that is why you were suspicious of 3.3 V and want me to add probes there, I will do shortly. Thanks for helping me debug!

[RobMeades]

Ummm, could be, I'm not really a HW guy I'm afraid, you know best!

[Paryavi]

Yeah, I added Saleae Probe D7 is VDD, Drain of Q5, which goes to SARA as VCC (after it has seen Q5 PMOS), and is an inversion of what we want(D0, Cell_enable power). Btw, sorry it is not clean VDD or VCC I will work on that.

So it sounds like Salea Probe D0; -DU_CELL_ENABLE_POWER_PIN_INVERTED is not an inversion signal on the MCU side(-DU_CFG_APP_PIN_CELL_ENABLE_POWER=19) as we require it to, right?

[RobMeades]

Well U_CELL_ENABLE_POWER_PIN_INVERTED is definitely the correct #define and you have corrected the spelling and, I guess, done a clean build; please do so if you haven't; remember that changing a #define passed to the compiler on the command-line hasn't changed the code so no "make" process will know to re-build the files in question.

[Paryavi]

Ok, I just rechecked the spelling, it is fine;

arduino-cli compile --fqbn esp32:esp32:esp32 --clean -v -u -p COM3 --libraries . --build-property compiler.c.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED -DU_CELL_ENABLE_POWER_PIN_INVERTED -DU_CELL_RESET_PIN_INVERTED -DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_R410M_02B -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19 -DU_CFG_APP_PIN_CELL_PWR_ON=0 -DU_CFG_APP_PIN_CELL_RESET=2 -DU_CFG_APP_PIN_CELL_TXD=1 -DU_CFG_APP_PIN_CELL_RXD=3" --build-property compiler.cpp.extra_flags="-DU_CELL_PWR_ON_PIN_INVERTED -DU_CELL_ENABLE_POWER_PIN_INVERTED -DU_CELL_RESET_PIN_INVERTED -DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_R410M_02B -DU_CFG_APP_PIN_CELL_ENABLE_POWER=19 -DU_CFG_APP_PIN_CELL_PWR_ON=0 -DU_CFG_APP_PIN_CELL_RESET=2 -DU_CFG_APP_PIN_CELL_TXD=1 -DU_CFG_APP_PIN_CELL_RXD=3" ubxlib\examples\sockets\sockets.ino

I recompiled it from the Arduino command-line interface to the board, the same issue exists. remember that changing a #define passed to the compiler on the command-line hasn't changed the code so no "make" process will know to re-build the files in question. So what do you recommend we do to change the code and make it re-build? I guess I should look at cli documentation. (We already have passed --clean that cleans up the build folder and does not use any cached build, I also run arduino-cli cache clean to command line before compiling).

I add the #define U_CELL_ENABLE_POWER_PIN_INVERTED to the header section in the sockets.ino code, it did not help.

[RobMeades]

Delete the build directory is the usual way, then you can see that all the object files have gone.

[RobMeades]

Just to be completely sure, you do have these lines in cell.h, i.e. as the master version here?

[Paryavi]

Yes, I was looking at them just now, also I am deleting the temp folder content now... C:\Temp\arduino-sketch-...

[RobMeades]

In every example and every test, when the cellular instance is created, it prints out what the "on" state of the Enable Power pin is (you've quoted such text above), so you could re-check that.

[Paryavi]

Not sure where can I check the print of cellular instance(uCellDeinit())? Normally I use Serial.print() and read the serial monitor. Btw, in Arduino IDE, Can I add #define U_CELL_ENABLE_POWER_PIN_ON_STATE 1?

[RobMeades]

Not sure I understand: can you not just look at the debug serial port output of the ESP32 chip? It's just as you have already quoted above ("U_CELL: initialising with enable power pin 19 (0x13) (where 0 is on)...").

[Paryavi]

You are right, previously when I was uploading code to feather board using USB cable in the Arduino serial monitor I would see more data; https://github.com/u-blox/ubxlib/issues/29#issuecomment-1002359875

Currently, I only see ATATAT... using FTDI programmer connected to the board. I am not sure if FTDI caused it or I need to modify some parameters. I will search for the ESP32 chip debugging tools, looks like Arduino CLI has a debugging tool...

[Paryavi]

Hi Rob, Platform IO has a great debugging environment, it supports Arduino and esp32, I was able to almost build ublox sockets example there, I get one error referring to u_cfg_os_platform_specific.h lines 97; 'CONFIG_ESP32_PTHREAD_TASK_PRIO_DEFAULT' undeclared (first use in this function)

[RobMeades]

Are you sure you are connected to the correct COM port of the FTDI chip on the board? What you're showing there looks like the port that is connected to the cellular module rather than the trace UART. When you boot the ESP32 chip I would expect to see a splurge of its boot output, e.g.

boot: ESP-IDF v5.0-dev-1554-g20847eeb96 2nd stage bootloader
boot: compile time 23:14:24
boot: chip revision: 1
boot_comm: chip revision: 1, min. bootloader chip revision: 0
boot.esp32: SPI Speed      : 40MHz
boot.esp32: SPI Mode       : DIO
boot.esp32: SPI Flash Size : 2MB
boot: Enabling RNG early entropy source...
boot: Partition Table:
boot: ## Label            Usage          Type ST Offset   Length
boot:  0 nvs              WiFi data        01 02 00009000 00006000
boot:  1 phy_init         RF data          01 01 0000f000 00001000
boot:  2 factory          factory app      00 00 00010000 00100000
...

Do you see that in your trace output?

As to the Platform IO thingy, looks like they are using a different version of ESP-IDF, I have a feeling that ESP-IDF changed their #defines for things at some point. Looks like it's become CONFIG_PTHREAD_TASK_PRIO_DEFAULT instead of CONFIG_ESP32_PTHREAD_TASK_PRIO_DEFAULT and, in the sdkconfig,h shipped with whatever version of ESP-IDF Platform IO uses, they've removed the backwards-compatibility entry that defined CONFIG_ESP32_PTHREAD_TASK_PRIO_DEFAULT to be CONFIG_PTHREAD_TASK_PRIO_DEFAULT.

For now you can just change CONFIG_ESP_PTHREAD_TASK_PRIO_DEFAULT to CONFIG_PTHREAD_TASK_PRIO_DEFAULT in the u_cfg_os_platform_specific.h for the ESP-IDF platform and I will make that change here also, might as well.