Testing to see if a command line option is set

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the -finstrument-functions gcc compiler (Atmel Studio) option and I want to do two things

- issue a compile-time warning that the option is on

- optionally compile in the entry/exit probes

 

I tried:

#ifdef INSTRUMENT-FUNCTIONS

 

but that didn't work.  I assume there is a general correspondence between command line options like -finstrument-functions and testable symbols but I have not been able to find documentation on it.

 

BTW: This is to try to find an obscure bug in my (ATMega1284p) code.  The symptoms change when I add code to try to trap it.  It 'smells' like a return onto a corrupt stack (execution jumps to invalid locations) but my efforts so far have been in vain.

 

Thanks in advance for your help.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume there is a general correspondence between command line options like -finstrument-functions and testable symbols but I have not been able to find documentation on it.

You know what happens when you assume ;-)

 

To my knowledge, there is no general mechanism which predefines macros corresponding to command-line options, whether implied or explicit.  You can invoke avr-gcc with -dM to see all defined macros:

$ avr-gcc -O1 -finstrument-functions -mmcu=atmega328p -dM -E - < /dev/null | sort | less

You will find no macro corresponding to -finstrument-functions.  You >>will<< find macros corresponding to >>some<< command-line options, such as -O1:

#define __OPTIMIZE__ 1

 

What else have to tried to track down your bug?  There are lots of techniques, the most powerful of which is likely to be in-circuit hardware debugging.  The ATMega1284p has JTAG.  Have you availed yourself of it?  Other options include stack painting, leaving bread crumbs in RAM or EEPROM, interrupt and function hooks, etc.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Mar 17, 2018 - 03:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
What else have to tried to track down your bug? There are lots of techniques, the most powerful of which is likely to be in-circuit hardware debugging. The ATMega1284p has JTAG. Have you availed yourself of it? Other options include stack painting, leaving bread crumbs in RAM or EEPROM, interrupt and function hooks, etc.

 

JTAG: yup, all the time

"stack painting"? - not familiar with this

 

Currently (in the debug environment) I'm using -finstrument-functions to verify the memory heap (structure) as well as heap/stack collision, verifying all linked list structures (many), etc.

 

I have been at this (programming) since about 1966 (my first on an Electrodata 205 [2000 vacuum tubes] my father maintained at a Community College in NY).  I am loath to blame a problem on a compiler or processor hardware.  The first processor hardware bug I discovered was about 1979 on a Tandem Computers, NonStop II processor (confirmed microcode bug).  Now it seams that I have spent days trying to track down a (seemingly random) bug in my code running on an ATMega1284P. 

 

The last straw was a (JTAG) breakpoint that was hit on an assert of a test condition invoked by the -finstrument-functions (checking a memory flag at the top of the heap to verify a 'magic' number to test for buffer overrun, etc.). 

 

if ((HighestUsed[0] != Memory_Magic) || (HighestUsed[1] != Memory_Magic) || (HighestUsed[2] != Memory_Magic))
    Restart( RM_Memory, 7, 0 );

 

I examined the variables being tested and all looked good.  Master interrupt flag was off (so, as far as I know, data could not have changed between the test and the breakpoint).  I then went into the Disassembler window and did a "Set Next Statement" to the start of the test ('if').  I stepped through the code and this time it succeeded.  Very much against all my better judgement, I was now suspecting hardware ...

 

I decided to try the same firmware on a different controller board (a product I designed and assemble) that used a lower frequency crystal (14.74 Mhz).  It worked flawlessly.  I tried another board with a 20.00 Mhz crystal (same as the board that was failing), it worked flawlessly.

 

All three processors are marked: ATMEGA1284P AU 1741 and VCC is 5.00 volts

 

As far as I can tell the datasheet confirms 20.00 Mhz @ 5.00v is ok.

 

So, it looks like I'm a victim of a chip that does not like 20.00 Mhz.  I may try a 14.74 crystal but that would just be for curiosity as I have switched to 20.00 Mhz for current production.

 

I have not yet verified that the clock is, indeed, 20.00 Mhz which is a distant possibility.

 

Is there firmware from Atmel that one can load into a ATMega1284P to check processor functionality?

 

Chuck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The 1284p has a known errata with high slew rate inputs to the pins adjacent to the Xtal1/2 pins. So if you're using that USART or otherwise using that pin as an input, high slew rate signals can upset the oscillator, causing apparently random behaviour including corrupted registers, including the PC.
Remedies are to use the full swing oscillator and/or manage the slew rate on that pin, usually by means of an RC filter.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

joeymorin wrote:
The 1284p has a known errata with high slew rate inputs to the pins adjacent to the Xtal1/2 pins. So if you're using that USART or otherwise using that pin as an input, high slew rate signals can upset the oscillator, causing apparently random behaviour including corrupted registers, including the PC.

 

In all cases the USART was being used (good and bad boards) ... but, your comment got me to thinking.  I assemble these boards using a Quad IVc SMT pick-and-place machine, after which they go into a reflow oven.  In the past I have had 0805 SMT resistors rise up and sometimes flip totally off the board due to the solder paste 'surface tension' when it flows into liquid solder.  Your comment made me check to see if the .22 pf SMT caps were on the board next to the crystal ... yes, they were ... but, upon closer examination one of them had lifted slightly and was not making contact due to imperfect 'wetting' !!

 

SMT 0805 Cap that did not "wet"

 

 

I have repaired it and it too works perfectly!

 

Thank you very much for the insight !!

 

Regards,

 

Chuck Hackett

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sneaky little devils those SMT SMD caps! ;-)

 

Glad you solved it.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Mar 18, 2018 - 03:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChuckH wrote:
I assume there is a general correspondence between command line options ... and testable symbols

On what basis do you make that assumption?

 

As noted, the ATMega1284p has on-chip debug - use it!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

As noted, the ATMega1284p has on-chip debug - use it!

Andy:

 

ChuckH wrote:

JTAG: yup, all the time

The last straw was a (JTAG) breakpoint that was hit on an assert of a test condition invoked by the -finstrument-functions

Note that the issue turned out to be hardware related.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

blush

 

although pretty sure that #5 and #6 weren't there when I posted.

 

I'd surely have noticed the picture?!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...