I am building IOT device using a LTE modem form Quectel, the BG95, together with NXP imx6, running Linux. The sim card I am using has the technology of eMTC.
Normally the device is working fine, the issue I am having now, is that the device lost LTE communication randomly (typically after 3-6 days uptime).
My setup
I have disabled echo mode in the BG95 at my init procedure.
I have a periodical call to send AT command "AT+CREG?" toward BG95, and read the response.
What I am seeing from the debugging is following:
My periodical at command "AT+CREG" toward BG95 is not responding.
Linux kernel reports ttyUSB towards BG95 is disconnected.
3-4 seconds, the kernel reports ttyUSB toward BG95 is connected again.
My periodical AT command "AT+CREG" toward BG95 is returning ERROR.
I see from the serial reading from the BG95 has "APP RDY".
I see from the serial reading from the BG95 has echo mode enabled.
Form what I am seeing, I am assuming that the BG95 is somehow "rebooted".
Is there any reason why the BG95 will reboot itself? Or how to confirm this?
I checked the datasheet of BG95, but I cannot find a AT command or other way to check the boot reason.
Do you have other suggestion on how to debug this further? Or similar experience with BG95?
Thanks
Related
I have a problem trying to change to run mode when the target device is the PLC (in local mode the problem disappears). It gives me the error: AdsError: 4115 (0x1013, RTIME: system clock setup fails). I have tried to execute win8settick.bat as administrator and rebooting so many times. I have checked the Hyper-V config and BIOS visualizator too. There is nothing that works for me. Any idea? Thank you
Ive only had this problem when trying to start it locally.
But one problem might be that the PLC time is way off. One suggestion to start troubleshooting would be to check the actual time on the PLC.
You can do this by either remotely accessing it via RDP or by plugging in a monitor and keyboard.
Sounds for me like a incompatibitility between TwinCAT-Realtime-System and the hardware. More exatly the CPU. What type of hardware do you use on your target system? Is it Beckhoff-Hardware or Third-Party. If third-party, which CPU?
Another topic could be the TC-Version related with the Target OS. Can you provide more information about this.
I tried to use KGDB on Ubuntu 14.04.2 - 3.16 kernel.
Target is running with 3.16 kernel on Ubuntu 14.04.2.
Host is running with 3.16 kernel on Ububtu 14.04.2.
Target is waiting for remote gdb connection.
Started my Host mechine and try to connect target..
$ gdb ./vmlinux
kernel image file of target machine.
$ gdb> target remote /dev/ttyS0
“unrecognized item timeout in qsupported response”.
Not able to proceed further. Can any one pass some lite on this?
The “unrecognized item timeout in qsupported response” error message most typically occurs when the serial connection between the debug station (GDB host) and target (SUT) is not running reliably in my experience. The usual solution is to do two things. FIRST, check the serial connection manually using a program such as minicom, setserial, and sty. (Check your baud rate match, and that characters appear to transfer between the two systems OK manually). Unfortunately, in my experience, the even with the correct RTS/CTS hardware flow control dongles interspersed, the KDBG agent on the target doesn't handle flow control well. So the manual test will appear to work (no real flow control with a manual test, but it does prove you have correct baud rate control on both ends and complete control). SECOND, and the typically required best solution in my experience is to lower the baud rate down to 9600. (Everyone starts at MAX, or 57600, or 34K, or 19200), but drop it to down to 9600. The data sent/received by the kernel debugger is small, and even the serial console doesn't generate a lot of data in debug situations. By locking the baud rate down to 9600, you wake sure the SUT serial kgdboc keeps up on the target, and the problem you are seeing usually goes away. If you find the speed too slow, once you have it running properly at 9600, then you can increase the speed back up one step at a time (on both ends) and find the maximum serial rate for your setup that works properly.
I'm rather unexperienced on the field of microcontrollers, I come from a Java background so the question might seem a bit noob but I didn't find much information on this.
So is it possible to debug an STM32F4 board via bluetooth (using eclipse or some othe IDE)? And if so could you send me some links that might help? We're building a robotic car controlled by a discovery board and debugging using an USB cable is not really an option if we don't want to disassemble the whole stuff every time something goes wrong. Hence this would really come in handy. So any help is appreciated
For doing this you would need to find a "Bluetooth Enabled" Debugger. I have never seen any and not sure whether there exists such thing or not.
I would suggest you one thing:
Assuming you have bluetooth connectivity between your board and your Machine,
Insert Debug strings: Send some strings from your board to your PC via Bluetooth. These strings will give you what's going on in Circuit.
For example, After Initialization, send "Init Completed" and like that. You can see these strings and see what's wrong.
I usually do this for my Wireless Device.
What you're wanting to do is really not practical; you're coming at this from way too high a level and trying to imagine the system as if it were running an operating system from the word go.
When you get the STM32 it as empty shell; you need to program it to do what you need to do and the only [sensible] way to get register-level debugging is to use a JTAG interface.
If, and this is a big if, you get it working reliably, but just want to give some debug information back while it is running, you could write a load of routines within the code to send out debugging messages when it enters certain parts of the program - and send it out over Bluetooth - but this is nothing like what you're used to single stepping through your Java code with Eclipse. If you want to do that kind of thing, you are going to have to put a little connector on that allows you to connect your JTAG or two-wire debugger cable to the processor. Even then, when you do that, you will be completely resetting your program and not simply single stepping through from where it went wrong.
You could insert a monitor program within your program to send out register values, program status etc over Bluetooth, but you still have to write the inital code and the only way to do this with out a ridiculous amount of trail and error is via your JTAG or two-wire interface.
Would this product work? It's a "IOGEAR Bluetooth Serial Adapter, GBC232A" for connecting to a serial port over bluetooth. I'm interested in wireless debugging too because my surface-clone dev computer only has one usb and this seems like it could be convenient over a tangle of usb cords and a usb hub. I have zero experience with any of this, so maybe you could validate or invalidate it as an option. I figure it just needs a proper serial connector wired up on the board and power from on-board?
Got a customer request but no idea can it be done. So need your opinions on this. This might be a utterly stupid thing to ask but yet need some facts so can work out best solution.
Scenario,
My Customer is an OEM Manufacturer. They make an automated system with a embedded touch screen (Windows XPe) this system got a button panel with some LED indicators (apart from keyboard) and 7 USB Ports. These button panels and USB ports are checked before sending to QC process. Currently a USB thumb drive with standalone executable with all indicators and controls flags is inserted to one of the USBs and then will run the exe. This exe capture user inputs from button panel and indicate which button is pressed so that it can be verify as working. And from program user can set LED indicators to different states (flashing, steady and off) so they can be verified as well. Once this is done then USB thumb drive will be inserted to each port and will verify it recognise. But after each verify step it needs to safely remove the drive from task bar. Once each test is finish user required to fill up the sheet with all pass and fail states for the entire button panel, indicators and USB ports. This is a quite length process when its come to mass production.
Apart from this embedded system all other components which suppose to connect to one of above embedded systems are tested via a program which I make and records all test outputs as they are tested. This program installed and components are connected to a testing embedded system.
Requirement,
What customer asks, can my program test completed embedded system with our host system (testing embedded system, may be via USB to USB) Its more like Testing a PC from another PC. Any ideas ?
Additional Info.
Apart from USBs there is one Network Port.
Thanks for looking, Feel Free to ask any questions. Any opinion is appreciated.
I'm not an expert on this topic, but it seems like this would be problematic because USB is an assymetrical protocol. There are hosts and there are devices. Hosts make the requests, and devices fulfill the requests. The problem is that PCs are USB hosts, not USB devices, so you would have two hosts trying to get the guy on the other side to do what he wants. Testing with a USB thumb drive worked because the thumb drive is a device.
It sounds like the unit to be tested doesn't have an ethernet port, which is a shame, because that would be the easiest way to go. If it has a serial port you could do it that way, but that is both slow and a hassle.
I am trying to make U9 telit modem send SMS messages. I think I handle protocol correctly, at least, I manage to send them, but only under these circumstances: the native application was executed beforehand, and killed by task manager (without giving it a chance to initialize things).
It looks like the supplied application is good at doing certain initialization/deinitialization which is critical. I also see the difference between the two states in output of AT+CIND command. When I am trying to do things on my own, it returns zeroes (including signal quality), but when I run the same command after killing the native application, the output looks reasonable.
I am out nearly of ideas. I have tried many things, including attempts to spy at modem's COM ports (didn't work). Haven't tried setting windows hooks to see what the application is trying to get thru.
Perhaps you have encountered a similar situation?
Agg's "Advanced Serial Port Monitor" actually helped a lot. Sometimes it caused blue screen, but it helped uncover secret commands which seem to help. AT+PCFULL is not described anywhere on the net, for example. The real trigger of non-operatio was AT+CFUN, the power disable/standby feature.
Also, it appeared that we have more issues. At first, the modem appears on the bus only as disk drive. It doesn't want to appear as any other devices before the drivers are installed. So, the U9 Telit software sends an IOCTL to disk driver to tell the modem to reappear as more devices (modem, 3 serial ports, another disk drive).