One point might be a too slow coming up power supply. How did you manage the xres on your board? Or are you using "Release" configuration?
Thanks for your response.
XRES is only used for debuggin, I followed the schematic from App notes that showed XRES connected directly to the 10-way header. When header is removed, nothing is connected to XRES.
The programmed target appears to boot and operate correctly. The very first thing is does is apply a hardware reset signal to the GSM modem and then blinks a LED at 500ms intervals 20 times (indicates it is in the initialisation delay preiod). It then lights up the LED to show it is checking the AT command but fails to acknowledge the "OK" response form the modem.
It fails every single time but on debugger it gets it every time ok.
Yes, I selected Released and then programmed the target.
Could there be a wrong clock setting that affects the Baud rate on the serial port when programmed but not when debugging?
Tomorrow, I will set my debug flag on and this spits our serial data from another port as it progresses through the code, I also have a putch to this debug port in the RX interrupt, so I can see what characters are being received when running stand-alone.
I did another project a couple of weeks ago that did not have the GSM modem (just and RF link) and it did not appear to have this issue. Both projects use the same hardware - except this model has the GSM modem plugged into it. (ie power supply is identical design).
I'm struggling to understand why there should be a difference. In the old PIC days when I used external crystal, I could have had this type of issue if I had not soldered the components on the board correctly or left the MCLR line floating. (PIC used an external pull up on reset)
Check if you have
1st declared all global variables as "volatile" that get changed in an interrupt handler
2nd when accesses those variables is not guaranteed to be atomic (ie. read-modify-write) encapsulated in a critical section.
I have attached the project. The AT command code is in "sms.h" whenit calls Send_AT routine at teh very top of that module.
I have used some EEPROM function in settings.c also, This is first time I have used the EEPROM, the data waved and read back seems to be ok.
GSMX6400.cywrk.Archive01.zip 3.5 MB
I had trouble setting the COM structs as volatile, would I just set the "Buf" element of the struct as volatile intead of attemtping to make the entire struct volatile?
Thanks again for your help Bob.
Your sms and com are not declared volatile.
I question if the statement
ptr = strtok(buf, "~"); // in settings.c line 203
which alters your buffer sms is interrupt-proof.
How to proceed:
You can define for each file separately to compile with "Debug" or "Release" setting. This has nothing to do with the process of debugging, it is "only" an optimization setting, "Releade" does not deliver good external (!!!) information for comfortable debugging.
So start to set one file after the other to "Release" and check the project for still running...
You have to use
volatile struct comtype COM;
extern volatile struct comtype COM;
extern volatile struct COM;
extern volatile struct SMS;
And changed the declarations in serial.c to match. Now I get this error when I compile...
Passing Arugument 1 of "Process Packet" discards volatile qualifier from pointer target type [enabled by default]
What do you mean about setting each file as debug or release? If I change the debug/release setting on toolbar, it appears to be global setting for the entire project
There are two differences that might come into play here.
First is the distinction between 'debug' and 'release' settings for the project. This affects the optimization settings - in release mode there are more aggressive optimizations active, and the memoty layout might be different (e.g. align to cache lines). Also, functions might be inlined and loops unrolled. Debug mode also might have additional instructions to allow setting breakpoints.
Second is using the debugger. This can be done in both project settings. But in release mode the machine code not always matches the source code 1:1 (making stepping through difficult). So usualy for debugging the debug setting is used. But stepoping through the code changes its timing.
So you should try:
- setting the project to debug, compile and program and see if it works. If the behaviour changes compared to the release mode, than the optimizations come into play. You can experiment with the settings for the release mode (e.g. disable optimizations, maybe even enable debug mode with -g) and see which one is the culprit. Also, the gcc manual has a list of all the optimizations that are done, maybe you can regocnize one that affects your code.
- try with and without the debugger attached. If this changes the behaviour, you most likely have a timinging issue / a race condition somewhere
What I usually try to do is: imagine by yourself 'I know this program has an issue that manifests itself so and so', then I go looking at the code and look for places that might lead to that problem. That way I can build a mental model of the program, and in most cases I can find the issue.
Thanks for the information.
I noted I had "Optional XRES" checked in system settings. Though the pin is floating, would this have an effect? (I physically have dedicated XRES connected to the 10 way header on my target.
Is the correct programming process to build and then select PROGRAM from the debug menu?
Today when I was playing around with it, the system performmed properly whether debug or release (as long as I left the miniprog 3 plugged into the target - without the debugger running in creator).
Relating to my last post. Does the miniprog 3 "let go" of the target and let it tun on its own when release is selected and it is programmed?
Since the MiniProg3 grounds your board (via the USB <--> PC) I would suggest you to check your power supply thoroughly. Best is to use an oscilloscope set to AC ahn high gain to see ripple and noise. Check with MiniProg applied and without.