Currently BC66 module have BC66NBR01A07 core firmware revision.
I am doing OpenCPU firmware using Eclipse kepler IDE.
In my firmware, I am toggling GPIO in while(1) loop.
Hardware Setup :
SIM card not inserted
Antenna not connected
Module Powered by external power supply 3.3V
Observations:
After Module Powered ON , following is the log observed on putty
F1: 0000 0000
V0: 0000 0000 [0001]
00: 0006 000C
01: 0000 0000
U0: 0000 0001 [0000]
T0: 0000 00B4
Leaving the BROM
Then module get restart automatically after around 30sec.
Module restart process still continue after around 30sec.
After restart, we observed the above same log on putty.
I’m using the same module I think the problem you’re talking about is the pwrkey problem pwrkey pin always make sure you give logic 0 When you use pwrkey should make logic 1, then should stop in logic 0.
In OpenCPU the Ql_OS_GetMessage() is the most important and the most “dangerous” function
The main task (all tasks) have hiden queue for periferal (all) callbacks and if you do not perform this function
the queue will overflow and application will crash or reset (BC66 reset, M66 crash)
If an event happens (example Timer expired -> timer_callback ) the RTOS kernel will send message to the task (where the timer was created) (where the callback was created) …
Hidden for the user Ql_OS_GetMessage processes this message and execute the registered callback
Exactly same issue here. I uploaded latest firmware BC66NBR01A07 to BC66 module (Olimex NB-Iot-devkit) and before it tcp_http (arduino version) worked great, but after the firmware update this reset problem came. Output is exactly:
Attention: my Arduino port is connected to firmware version ( this port is not official product of Quectel )
if you update firmware you need pre-compile application…
Arduino have application blocker for wrong version
If Quectel made changes in version 7 I dont know that… but I dont see changes in Ql_OS_GetMessage
this function is most important and process all user callbacks