Announcements
IMPORTANT: Cypress Developer Community is transitioning on October 20th. To learn more and be prepared for this change, check out our latest announcement.
cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1 MCU

DaHu_285096
Contributor II

 I was wondering if there were any spcific major changes when  code is running in the target (after programming) compared to when running on debugger (J-TAG interface via Miniprog 3). The target does not use external crystal.

   

The code appears to work fine when debugger attached, when I unplug the bebugger the code does not operate the same. The code initialises a GSM modem. When not on debugger, It does not appear to process data received back from the modem properly. Yet, the same routines have been working without error over debugging for last few days.

   

If I program the target and leave the debugger connected (even without running the code in creator, it is ok). 

0 Likes
34 Replies
Bob_Marlowe
Expert II

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?

   

 

   

Bob

0 Likes
DaHu_285096
Contributor II

 Hi Bob,

   

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)

0 Likes
Bob_Marlowe
Expert II

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.

   

 

   

Bob

0 Likes
DaHu_285096
Contributor II

 Bob,

   

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.

0 Likes
DaHu_285096
Contributor II

 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.

0 Likes
Bob_Marlowe
Expert II

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.

   

 

   

Bob

0 Likes
Bob_Marlowe
Expert II

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...

   

 

   

Bob

0 Likes
Bob_Marlowe
Expert II

You have to use

   

volatile struct comtype COM;
 and
extern volatile struct comtype COM;
 

   

 

   

Bob
 

0 Likes
DaHu_285096
Contributor II

 I used

   

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]

0 Likes
DaHu_285096
Contributor II

 Bob,

   

 

   

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

0 Likes
HeLi_263931
Honored Contributor II

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.

0 Likes
DaHu_285096
Contributor II

 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).

0 Likes
DaHu_285096
Contributor II

 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?

0 Likes
Bob_Marlowe
Expert II

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.

   

 

   

Bob

0 Likes
ETRO_SSN583
Esteemed Contributor

If you are looking for noise and have a DSO -

   

 

   

1) Set vertical for infinite persistence.

   

 

   

2) Look at rails to see pk-pk noise. Use polymer tants for bulk, they have ~ 10x better Z(f) curves

   

than normal tants. And as always .01 uF ceramics. Look at cap datasheets, not all caps are

   

equal in performance, C vs V, esr......

   

 

   

3) Normal persistance, set trigger V < Vssd, normal mode, and scan each pin looking for a

   

trigger.

   

 

   

4) Normal persistance, set trigger V > Vddd, normal mode, and scan each pin looking for a

   

trigger.

   

 

   

5) Also use runt pulse qualifier to capture anything that does not look like code created

   

waveform. Normally a runt << period of code created switching.

   

 

   

If analog scope you can still use trigger to qualify pk-pk noise, just a little more complicated.

   

 

   

A good reference on layout - www.google.com/search

   

 

   

Regards, Dana.

0 Likes
DaHu_285096
Contributor II

 The hardware works fine with oethr projects, it is possible there is an assembly issue (pin not soldered correctly).

   

Decoupling is using low ESR caps right under the IC and next to the VC, VA, Vdd and VDDIO pins.

   

The LED sequence start up etc are all working ok and the target is grounded to the PC through the COMs cable for the Gui.

   

If there is nothing obvious that needs doing (like a clock setting or programmer setting or something), I suspect it might be related to interrupts correpting variables.

   

Are you able to suggest how I can fix the compiler warning when the struct is made volatile?  

0 Likes
ETRO_SSN583
Esteemed Contributor

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.

   

 

   

Sounds like a delay sensitive issue in I2C (if thats interface to GSM) ? Not the

   

first time on forum delays have solved some issue, but unless you can establish

   

this thru datasheet timing on GSM leaves no comfort you have the right delay.

   

 

   

Regards, Dana.

0 Likes
DaHu_285096
Contributor II

The interface to the GSM is Serial port (UART) at 115200 Baud.

   

A command is issued and expected reply within 200ms for AT response.

   

When the modem initializes, there is delay until a valid response is obtained after reset. The program is put into a loop and issues the AT command ....

   

While I am writing, I thought of another aspect. It might be an issue with the start up time of the modem. Though I was resetting the modem while debugging, I was not cycling the power. 

   

Does anyone know if the Miniporg 3 releases itself from the target when you set release mode and "program" from the debug menu in creator? If so, I can test it now from home by RDP into my workstation and send myself a text.

0 Likes
ETRO_SSN583
Esteemed Contributor

I compiled this test case, 5LP, w/o any errors -

   

 

   

volatile struct {
    uint8 myvar1;
    uint16 testray[ 8 ];
};

   

 

   

Regards, Dana.

0 Likes
Bob_Marlowe
Expert II

Regarding Debug / Release compiler setting for single files

   

For selected files you may changhe the options used for "Debug"-settings individually:

   

In Creator right click on the .c-file and select Build Settings -> Compiler -> Optimization and set the Optimization Level to "Size" or "Speed"

   

 

   

Bob

0 Likes
DaHu_285096
Contributor II

 Dana,

   

When I compile what you did in my header file like below.. I get errror "useless type qualifier in empty declaration"

   

    

   

volatile struct comtype

   

{

   

  char   Buf[BUFSIZE];

   

  uint8  DataBytes;

   

  uint32 Timer;

   

  uint8  DatainBuf;

   

  uint8  State;

   

  uint8  Timeout;

   

};

   

 

   

extern struct comtype COM;

   

extern struct comtype SMS;

0 Likes
HeLi_263931
Honored Contributor II

The question regarding the MiniProg is best asked to Cypress. But what I expect is the following behaviour:

   

- when you start a debug session, and then at one point (possibly directly after the first breakpoint at the start of main()) hit 'run' I would expect MiniProg to still have a hold of all lines (including XRES) (since you need to get access to the target e.g. for pausing the program

   

- directly after programming, without starting a debug session, I would expect MiniProg to release all lines

   

I might be wrong with the latter part, though, and MiniProg still holds the lines at defined levels. This is something you should be able to check e.g. with a scope. Or you just connect a temporary resistor to your XRES line (e.g. 1M or so) to get it do a defined level.

0 Likes
HeLi_263931
Honored Contributor II

Btw: optional XRES means that the XRES pin is located at pin P1[2]. The recommendation is to do this only for to 48-pin SSOP devices and to use the dedicated XRES pins otherwise.

   

AN61290 (http://www.cypress.com/?rID=43337 ) shows no special handling for the XRES pin (except when its at P1[2]), so you should be fine. (And the TRM says that XRES_N is pull-up internally).

0 Likes
DaHu_285096
Contributor II

 Thanks Bob,

   

I took a look and found the dialog using the right click on the C file. They are all set to Debug at the moment, even though project is set to release.

   

I can change them 1 at a time and see if any issue turns up

0 Likes
DaHu_285096
Contributor II

Thanks ALL for your help.

   

I have plenty to try when I get to the office in the morning.

0 Likes
Bob_Marlowe
Expert II

The settings will be "Debug" all the time!

   

You may define two different sets of settings: one is named Debug and the other Release. You have to change some of the settings for compiler optimization.

   

 

   

Bob

0 Likes
ETRO_SSN583
Esteemed Contributor

This compiled for me, no errors, no warnings -

   

 

   

#define BUFSIZE 10

volatile struct {

  char   Buf[BUFSIZE];
  uint8  DataBytes;
  uint32 Timer;
  uint8  DatainBuf;
  uint8  State;
  uint8  Timeout;

} comtype;

extern struct comtype COM;
extern struct comtype SMS;

   

 

   

Funny thing though I would have thought lack of defines in another file of COM and SMS

   

would have generated a fault, warning, whatever. Once again C eludes me and reminds

   

me I am going crazy a mm at a time, slowly.

   

 

   

Regards, Dana.

0 Likes
DaHu_285096
Contributor II

 Your compiiler and/or settings must be differene to mine. Attached is screen shot of result when I attempt to make the struct volatile.

   

 

   

Another thing I notice is that if I move the struct name "comtype" down to after the parenthesis, I get the error "Build error: invalid use of undefined type 'struct comtype' for every place the structures are used in the interrupt file.

0 Likes
DaHu_285096
Contributor II

 I could only attached one image in last post. Attached is screen shot for when I compile with struct as volatile type.

0 Likes
DaHu_285096
Contributor II

 I also mentioned I could not single step the debugger due to the timer interrupt going off. When I looked this issue up, it appeared the problem is the timer is in hardware and it contunies to run at full speed so it continually times out while I debug.

   

However, I have used a simple 1khz clock component to drive the 1ms timeout function (as attached).

   

Does the "Timer" component do this same thing? I was used to microcontroller where single stepping also single stepped the timer interrupts and the code was more like a simlulator when single step debugging (each step represented only the time of the step to the timer instead of the timer continuing to run at full spee).

0 Likes
DaHu_285096
Contributor II

 Would help if I attached the file before posting.

   

By the way, while I notice. I had trouble connecting off chip items (like the resistors and diodes shown on right) when the pins were connected to another signal. I also tried enabling the extended pin function but kept getting errors about signals not being connected properly.

   

It worked ok for pins on their own, like the ones on top left of schematic.

0 Likes
DaHu_285096
Contributor II

 I found if I set the structs as volatile, the errors were in the USE of the struct only when it was part of a parameter passing to another function.

   

 

   

What I did was modified the calls like this Process_Packet((char *) COM.Buf); (ie. cast as char)

   

Now it compiles cleanly. I suspect now it should be interrupt safe? The struct used inside the interrupt have not been change or re-cast, only the calls to code that processes the buffer (strstr and strtok etc).

0 Likes
DaHu_285096
Contributor II

 Thanks again ALL.

   

The code is running correctly on its own in the target.

   

No hardware changes were made, so it was not an earthing, reset or noise issue.

   

I did not alter any of the release/debug or compiler settings for the C files, so I think that was not the issue

   

I think BOB was right with regard to the variables not being interrupt safe. changing the structs to volatile, I believe this was the issue.

   

Next, I will see if changing the clock component to a timer will enable me to single step debug without every step ending up in the interrupt routine.

0 Likes
ETRO_SSN583
Esteemed Contributor

Take a look at this as well -

   

 

   

www.cypress.com/

   

 

   

Regards, Dana.

0 Likes