Having Some non specific Issues

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

Hi 

 

AS7/MS7

2560 RobotDyn (non genuine 2560)

and using Xloader to program hardware.

other than a code indent highlighter addin a standard install of AS/MS7

 

Just after some opinions from the great unwashed!!!

 

Whilst I wait for MS7 to uninstall and hard drive checking to complete I thought I'd post a question here about some issues I am finding with MS7 and see if my issues are my naivety or an actual problem.

 

I am increasingly finding my code is not working properly when I upload it to my 2560 development board. Because I am new to C programming and the AS/MS7 environment I can't help think I am doing something wrong but I am beginning not to think this is not the case.

 

Now the first I noticed was that my serial port configuration and data transfer didn't seem to be that reliable. No matter how many times I power cycled nothing worked. Very often I would program the same code again and it would work as expected. Often if I copied my code into ArduinoIDE it proved to be more successful.

 

I did post a question recently and  a contributor suggested as I am an ISR I make sure the internal pull-ups where enabled OK but the issues still occasionally reoccur. Then was the situation that for 1 byte change in a while loop eg. 0xBf to 0xBC caused a 2K, 300B or 600B difference in compiled code. Then there was a situation that when I was simulating code the simulator dropped out of the normal look when at the end of a function and start stepping through the code in a disassembly window and all my watch variable didn't update. 

The latest is that my previously working 'top half' of my code which included the standard _delay_ms(2) stopped working then started working with 2ms delays now 1ms. However if I changed them to _delay_us(2000) it would work once on than stop, change back to ms work again for a couple of runs. then stop or change the time base again to 1.5mS aarrgghh!!

Yes - the first line of my code specify the F_CPU 16MHz base speed.

 

I have 'repaired' AS7 a couple of times and it doesn't seem to help, Like I said I am now completely uninstalling/reinstalling like I said I'm just curious what others think - how many times can these be reprogrammed without beginning to fail? Are they like EEPROMs and only have a certain number of flash program cycles?

 

Ove rto you chaps and chapesses

Thanks

 

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

 how many times can these be reprogrammed without beginning to fail?

Many!

 

It is extremely unlikely that you have hit hat limit.

 

Your post seems to mention two issues, one with the AS7 simulator, and another with the code for your M2560.

 

Reloading AS7 won't have any impact on a bug in your code!

 

For the code issue, with the delay function, you likely need to ignore your overall program and write a simple test program that uses the delay, (toggle an LED< or whatever).

Make sure that is working properly.

 

Then slowly add in other parts of your project.

 

Does a simple ISR work, or does adding the ISR initiate the failure?

 

JC 

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

What is the clock source for your board? internal R/C or external xtal?

Please post the fuse settings as read from the AVR.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Docara wrote:
2560 RobotDyn (non genuine 2560)

What does this mean?   post a link to the board or post a clear picture.

 

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Hello all 

Hope you're keeping your eye on Spacex's Starship & Labpadre (youtube) they are go for the second flight.

 

Right back to business

 

Jim 

The reason why I stated non genuine is that it is VERY hard to see any markings on chip AND the designation (from memory) something like 16u or similar doesn't show up as a valid code on Microchip site.

Clock is external 

LINK

Sorry - Could you explain how I can read the fuse settings directly  

 

Heres a couple of screen grabs

 

Beginning of Prog - please ignore crap in F_CPU happen during screen grab

 

 

 

 

Beginning of Code - Just setting up USART registers using multiple SWITCHs and sending out 1Byte for calibration.

Please refer to resulting timing pic below

 

 

Resultant timing diagram. These timing have been spot on 2 & 4ms previously with same code.

 

 

Again with regards the simulator it did work fine - then it didn't. Surely I couldn't mess up the Simulator using my code- could I?

 

Lastly, reference writing a short timing delay - Before I posted here I did try Blink in Arduino (and programmed with ArduinoIDE) seems to work fine

 

 

Last Edited: Mon. Jan 25, 2021 - 09:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I see it's an Arduino Mega cloan, so what jtag debugger are you using?

Fuses should be set as in an Arduino Mega......   if you have a jtag debugger attached, then you use AS7 to read the fuses. But if your using the Arduino bootloader, it can not be read.

If you really want help with this, zip up your AS7 project directory and attach the zip file to a posting, then a freak who has a mega can dig into it and help you.  I do not.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

HI Jim

 

After making Google my new friend - I'm looking to knock up a basic Arduino ISP tomorrow and run Avrdude and see if will read the fuses - the other alternative is get a 328PB mini Xplained board. My code is portable enough to just load straight onto a 328PB as is. Anyway, I'm hitting too many strange problems so I think a debug board is long overdue. I really need to see what's going on an a hardware level.

 

Thanks you again for sparing some time to answer my post,  I will report back if I find anything of interest. Oh! are there any fuses in particular you want to know about?

 

G'night 

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

Afernoon Jim,

 

Please find enclosed what fuse settings I could acquire

 
 

Programming mode off.

Atmega chip detector.
Written by Nick Gammon.
Version 1.20
Compiled on Jan 26 2021 at 12:46:25 with Arduino IDE 10812.
Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x98 0x01 
Processor = ATmega2560
Flash memory size = 262144 bytes.
LFuse = 0xFF 
HFuse = 0xD8 
EFuse = 0xFD 
Lock byte = 0xFF 
Clock calibration = 0x85 
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 8192 bytes starting at 3E000

 

ADDITIONAL

Atmega fuse calculator.
Written by Nick Gammon.
Version 1.11
Compiled on Jan 26 2021 at 13:18:41 with Arduino IDE 10812.
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x98 0x01 
Processor = ATmega2560
Flash memory size = 262144
LFuse = 0xFF 
HFuse = 0xD8 
EFuse = 0xFD 
Lock byte = 0xFF 
Clock calibration = 0x85 
OCD Enable.............................. [ ]
JTAG Enable............................. [ ]
Enable Serial (ICSP) Programming........ [X]
Watchdog Timer Always On................ [ ]
Preserve EEPROM through chip erase...... [ ]
Boot into bootloader.................... [X]
Divide clock by 8....................... [ ]
Clock output............................ [ ]
Bootloader size: 8192 bytes.
Start-up time: SUT0: [ ]  SUT1: [ ] (see datasheet)
Clock source: low-power crystal.
Brownout detection at: 2.7V.
 

Edit  from Info on Nicks site concerning bugs in 2560 bootloader I have subsequently reflashed the bootloader with Nicks code

Consequently the new fuse settings are

 

Signature detector.
Written by Nick Gammon.
Compiled on Jan 26 2021 at 13:53:00 with Arduino IDE 10812.
Signature = 1E  98  01 
Fuses
Low = FF High = D8 Ext = FD Lock = EF 

Processor = ATmega2560
Flash memory size = 262144
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 8192 bytes starting at 3E000

 

 

Last Edited: Tue. Jan 26, 2021 - 01:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have test gear to measure your clock?  Most multimeters won't, some expensive ones will.  An oscilloscope would be even better.  Consider programming the 'clock out' pin.

 

Suggest you put in some startup time.

 

Have fun, and carry on!  S.

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

Hi Scroungre thank you for your suggestion. 

 

 

Gawd I wish - unfortunately I don't. However I do think the basic logic analyser I have is accurate enough to gain some idea what's going on. For example I need a Baud rate of 9600 for calibration purposes to start negotiation with another chip. Now considering 9600 Baud is approx 166uS per bit, I am showing 104uS - I'm in the ball park considering margins of error with a non calibrated piece of kit also acknowledging @16MHz - 9600 Baud the 2560 has 0.2% error anyway according to data sheet.

 

I will do as suggested and report back

 

 

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

Ahh.  You may have slightly misunderstood the data sheet.  When the 2560 tells you that at 16MHz it has 0.2% error at 9600 baud (presuming you've set your UART registers correctly) it's not that the chip has 0.2% error - it's that the counters only have enough resolution to get within 0.2% of the desired clock speed.  If you wanted an exact baud rate speed, you should have chosen a crystal that gives you one - they're out there - it's not the chip's fault, it's your clock's fault.

 

Given that, I don't think 104uS when you're expecting 166uS is anywhere near 0.2% error.  More like 40%, no?  No wonder it doesn't work.  S.

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

Docara wrote:
Now considering 9600 Baud is approx 166uS per bit, I am showing 104uS
What are you talking about? 104us is the well known bit width at 9600 baud. If you are observing 104 you are seeing exactly the right thing.

 

Think about it 1/9600 = 1.0416666666666666666666666666667e-4 (Windows calculator!) that sure looks a whole lot like 104us to me!

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

Docara wrote:
Now considering 9600 Baud is approx 166uS per bit, I am showing 104uS

104 is the correct bit time for 9600 baud, not sure where the 166 came from.....

Perhaps you were dividing by 8 instead of 10 (start and stop bits count for a total of 10bits per byte)

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I'm not going to give you the equation - you can Google it just fine, but I will give you a litl' rule o' thumb.

 

Imagine if you wanted 100uS per bit.  Then 0.2% allowed error would say you can have 99.8uS per bit, or 100.2uS per bit.

If you wanted 200uS per bit, 0.2% allowed error would be 199.6uS or 200.4uS.

Halfway in between, 150uS per bit would therefore allow (ish) 150.3uS or 149.7uS.

In absolutely no way would 166uS per bit allow 104uS per bit.

 

Follow?  S.

 

PS - Strictly technically, the metric unit for seconds is a lower-case s, not upper-case; that's Siemens - but given that I typed 'u' for 'micro' all the time and you like using the upper-case S, I felt like speaking your language was more important than being strictly technically correct.  You're welcome.  cheeky  S.

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

aaarrghh 

 

Typos and brain farts gentlemen - I feel suitably chastised!!!!blush (should have been 106) and yes I was thinking about 10bit frame blah blah. I've just searched SI unit for second  - lets move on eh! I wont mention that when I just wrote micro second (see what I did there cough cough) on a piece of paper I used a lower case S. (if someone could point me in the direction of a middle finger emoticon I would be grateful LOL)

 

Ok so I have reinstalled MS7 did a small blink with various delays values and they where all spot on as displayed with LA. 

 

I've just rerun my original code and the timings are even worse than they were before. I haven't changed the fuse settings yet to output clock  - can this be done within the compiled code with Atmel? 

 

Let me do some digging there's something strange going on somwehere.

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

Scroungre wrote:
PS - Strictly technically, the metric unit for seconds is a lower-case s

 

even more strictly, it's the SI unit

 

https://www.nist.gov/pml/weights-and-measures/metric-si/si-units

 

https://www.nist.gov/pml/weights-and-measures/writing-metric-units

 

cheeky

 

 

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

Right  an update

 

Latest screen grab

 

 

Now here's what I am facing:-

Putting the following code :-

 

                                 DDRD |= (1 <<(DDD3));

                                        while (1) 
                                                    {
                                                          PORTD ^= (1<<(PD3));
                                                         _delay_ms(2);
                                                    }

 

into my software in various locations around my software the resulting pulses are correct (as can be seen above).

My pulse width per bit via USART for 9600 Baud is spot on.

However, it seems when I put _delay_ms(2) where I need it, be it inside a function or between function calls, it does not produce 2ms delays that I require. 

Why does it work in one place and not the other?

 

Where would you guys look to find out what and why is going on here - I remind you all this was working fine until it wasn't - I wonder if the 2560 is faulty.

 

I'm at a loss  

 

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

If you ask for 2ms and get 1ms (roughly) then it suggests you have given the wrong F_CPU value to <util/delay.h>. It should be double what delay.h is currently seeing.

 

That's actually a bit odd as this thread seems to suggest that you are specifying 16000000UL which would rather seem to suggest the CPU might be running at 32MHz. Try setting the CKO fuse and look at the CKO pin with your scope - what clock speed does it see?

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

Could a recent windows10 update have broken MS7??

 

This all started after an update when the simulator started dropping into disassembly mode randomly at the end of one of my functions and it's been down hill ever since.

 

The following was always rock solid,  now I can't even get the code to complete in the simulator.

Would someone please simulate the following at see if it completes - I can't get the simulator to reach i = 0x4.

Now I might have cocked something up during cutting and pasting but I can't see for looking.  

 


#define F_CPU 16000000UL	// Define MCU clock speed (for delays only)

#include <stdint.h>		// Needed for uint8_t
#include <avr/io.h>		// AVR Pin and Register Names
#include <avr/interrupt.h>	// AVR Interrupt Vectors
#include <util/delay.h>		// Usage -> milli seconds  = '_delay_ms(50);' micro seconds = '_delay_us();'

//////////////////////    USART Definitions	  //////////////////////

//	USART Ports
#define USART0				0x01
#define USART1				0x02
#define USART2				0x03
#define USART3				0x04

//	Baud Rates
#define baud_4800			0x00	//	0xCF	UBRR Value used in Usart_Speed_Setup	
#define baud_9600			0x01	//	0x67	UBRR Value used in Usart_Speed_Setup	
#define baud_19200			0x02	//	0x33	UBRR Value used in Usart_Speed_Setup	
#define baud_28800			0x03	//	0x21	UBRR Value used in Usart_Speed_Setup
#define baud_38400			0x04	//	0x19	UBRR Value used in Usart_Speed_Setup
#define baud_57600			0x05	//	0x10	UBRR Value used in Usart_Speed_Setup	
#define baud_76800			0x06	//	0x0C	UBRR Value used in Usart_Speed_Setup
#define baud_115200			0x07	//	0x07	UBRR Value used in Usart_Speed_Setup	
#define baud_2500000		        0x08	//	0x03	UBRR Value used in Usart_Speed_Setup

//  Baud Rate Array
const uint8_t BaudArry[9] = {0xCF, 0x67, 0x33, 0x21, 0x19, 0x10, 0x0C, 0x07, 0x03};	// Declare a 9 way array called 'BaudArry'
																					// and put in the UBRR values from above

//  Initial USARTs Setup - Asynchronous, 8 Data, Stop, no Parity
#define	UCSRnC_Val			0x06			//	UCSRnC_Val = 0b00000110  	'n' indicates Port Number - 0,1,2,3
#define TxRxEn				0x18			// 	Enable TXENn and RXENn Bits in UCSRnB Register

//  Function Declarations
void Usart_Init_Setup(void);				       // AVR USART configuration [All 8:n:1]
void Usart_Speed_Setup(uint8_t, uint8_t );	               // Format [Port, Speed] - Used for setting Port and Baud Rate





int main(void)
{
	uint8_t i=0;	
	
		Usart_Init_Setup();								
		Usart_Speed_Setup(USART0,baud_9600);				
		Usart_Speed_Setup(USART1,baud_9600);			
		Usart_Speed_Setup(USART2,baud_9600);				
		Usart_Speed_Setup(USART3,baud_9600);			
     

      i = 0x42; // debug in Simulator
     
    while (1) 
    {
    }
}

void Usart_Init_Setup(void)
{
	// Basic 8,n,1 configuration of the 4x MCU ports of the AtMega2560 and enable Transmitting & Receiving 
	// UCSRnC_Val = 0x06	    8 Bit Data	  (UCSZn1 and UCSZn0 = 1)
	// TxRxEn =				Tx and Rx Enabled (0x18)
	
		
/*
		DDRJ &= ~(1<<0); // configure PBJ as an input
		PORTJ |= (1<<0); // enable the pull-up on PBH
		DDRH &= ~(1<<0); // configure PBJ as an input
		PORTH |= (1<<0); // enable the pull-up on PBH
		DDRD &= ~(1<<3); // configure PBD as an input
		PORTD |= (1<<3); // enable the pull-up on PBD
	*/	
		
		UCSR0B = TxRxEn;		// USART 0
		UCSR0C = UCSRnC_Val;
		UCSR1B = TxRxEn;		// USART 1
		UCSR1C = UCSRnC_Val;
		UCSR2B = TxRxEn;		// USART 2
		UCSR2C = UCSRnC_Val;
		UCSR3B = TxRxEn;		// USART 3
		UCSR3C = UCSRnC_Val;
		

	return;
}
void Usart_Speed_Setup(uint8_t Port, uint8_t Speed)
{
	// Function to Write Baud Rate of the 4x Serial Ports of the AtMega2560

	switch (Port)
				{
		
					case 1:
						UBRR0L = BaudArry[Speed];
					break;
			
					case 2:
						UBRR1L = BaudArry[Speed];
					break;
			
					case 3:
						UBRR2L = BaudArry[Speed];
					break;
			
					case 4:
						UBRR3L = BaudArry[Speed];
					break;
									
				}
	
	return;
}

 

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

I'm beginning to think that you might be right about AS7. Perhaps a recent update has broken something. I tried pasting your code into an existing project, setting it to 2560 then building and simulating. But when I try to do one of my standard things which is to start simulation, break at main and then "goto disassembly" it says there is on accessible code. Which is most odd.

 

In case I broke something in that existing project I created a whole new one but had the same thing.

 

Not sure what's going on ?!

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

Docara wrote:
Could a recent windows10 update have broken MS7??
That's possible or instead a .NET update (Microchip Studio 7 is from Visual Studio Isolated Shell 2015 which is heavily dependent on .NET)

Atmel Studio 7.0 new install on Windows 10 2004 - not starting | AVR Freaks

Another Win_10 rant of frustration-part 2 | Page 3 | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

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


clawson wrote:
break at main and then "goto disassembly" it says there is on accessible code.
More curious still - just tried it again and if I dismiss the alert when it happens then try a second time it DOES go to the Asm ?!?

 

Will try 2560 and the code above now..

 

EDIT: Wow I had to dismiss the spurious dialog three times before it would let me see the Asm code but then it showed:

 

and I was able to step it all easily. as you'll see a large proportion has been optimised away - that function with the switch to set 4 baud rates has simply turned into four precalculated STS opcodes but the code certainly seems to follow the execution sequence I would expect.

Last Edited: Wed. Jan 27, 2021 - 04:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you clawson for trying.

 

Would you be kind enough to manually step though the code and see if it hits i=0x42 in a watch window. Also, randomly comment out one or more of the following and see what happens of your system

                Usart_Speed_Setup(USART0,baud_9600);				
		Usart_Speed_Setup(USART1,baud_9600);			
		Usart_Speed_Setup(USART2,baud_9600);				
		Usart_Speed_Setup(USART3,baud_9600);	

 

I am still new to this and not 100% confident in the code I write - all this has knocked my confidence somewhat and would like to know if my code is OK.

 

Hello GChapman,

Just to be clear are you suggesting I act on the post (first one) concerning updating .NET or did you post them for informational purposes?

Thanks 

 

 

For completeness I am running 7.0.2542 & Windows10 Pro 1909 - I delay the damn updates as long as I can and it looks like there's one pending know. 

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

You edited when I was replying 

 

My simulation hangs randomly at the end of a Usart_Speed_setup(*****,***) usually, but not always, at the last one of however many setups were not commented out. (Bad English I know, but on the up side I now use small s's for seconds when I type)

 

Does this happen to you?

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

information; once you're certain the defect is in Windows 10 or .NET then create your action (one has ten days to roll-back an update)

Windows 10 1909 is good to go (broadly deployed)

Delaying (Home) or deferring (Pro and sub) Windows 10 and .NET updates is prudent; ones at Microsoft need a few weeks to correct defects (only a relative few security updates are recommended to be immediate)

 


Release of Microchip Studio 7.0.2542 | AVR Freaks

Windows 10, version 1909 and Windows Server, version 1909 - Windows Release Information | Microsoft Docs

 

"Dare to be naïve." - Buckminster Fuller

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

Docara wrote:
see if it hits i=0x42 in a watch window
Well it's never going to hit that. Surely you saw when the compiler said:

		.././main.cpp: In function 'int main()':
D:\test\newtest\main.cpp(45,10): warning: variable 'i' set but not used [-Wunused-but-set-variable]
		  uint8_t i=0; 
		          ^

There's going to be nothing called "i" and no code accessing it in the code that you are building. If you really want "markers" that you can break on I personally prefer:

asm("nop");

but someone will be along in a minute to point out that you don't need to type that as _NOP(); is available. But you need a #include of <avr/cpufunc.h> to use it (so just typing asm("nop") could be easier!!)

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

Yes I saw that but at this stage I just don't trust anything from AS7 which is why, at least in part, I asked you to step through.

 

Further to your statement, I don't fully understand why it is not used!  If I declare a variable then later write to that variable surely I have used that variable.

Do I have to buy the compiler dinner or get a letter from it's mum to say it can come out to play???

 

I swear it's harder learning 'compiler' than it is C 

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

Docara wrote:

Further to your statement, I don't fully understand why it is not used!  If I declare a variable then later write to that variable surely I have used that variable.

Do I have to buy the compiler dinner or get a letter from it's mum to say it can come out to play???

You probably need to read:

 

https://www.avrfreaks.net/forum/...

 

GCC is an aggressive optimising compiler and will discard anything that looks pointless at the earliest opportunity. If you write:

int main(void) {
    int i = 123;
}

this will basically compile to "RET" and nothing else. At build time the compiler will warn "i is set but never used". As it's never used the compiler will be thinking "why would I bother wasting space or run time machine cycles to create a variable that has no apparent use?" So it doesn't,

 

The way to over-ride this is to make the variable "volatile" which says to the compiler "you and I can both see this is entirely pointless but just do it anyway - create some code for no reason whatsoever".

 

It'll be the difference between:

000000fa <main>:
int main(void) {
    int i = 123;
}
  fa:	80 e0       	ldi	r24, 0x00	; 0
  fc:	90 e0       	ldi	r25, 0x00	; 0
  fe:	08 95       	ret

and

000000fa <main>:
int main(void) {
  fa:	cf 93       	push	r28
  fc:	df 93       	push	r29
  fe:	1f 92       	push	r1
 100:	1f 92       	push	r1
 102:	cd b7       	in	r28, 0x3d	; 61
 104:	de b7       	in	r29, 0x3e	; 62
    volatile int i = 123;
 106:	8b e7       	ldi	r24, 0x7B	; 123
 108:	90 e0       	ldi	r25, 0x00	; 0
 10a:	9a 83       	std	Y+2, r25	; 0x02
 10c:	89 83       	std	Y+1, r24	; 0x01
}
 10e:	80 e0       	ldi	r24, 0x00	; 0
 110:	90 e0       	ldi	r25, 0x00	; 0
 112:	0f 90       	pop	r0
 114:	0f 90       	pop	r0
 116:	df 91       	pop	r29
 118:	cf 91       	pop	r28
 11a:	08 95       	ret

(but if you are worried about filling up your limited AVR with cycle wasting, flash space wasting code you would presumably prefer the former?).

 

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

Docara wrote:
 If I declare a variable then later write to that variable surely I have used that variable.

No, you haven't.

 

If all you do is write to it, then nothing ever reads what you wrote, the effect of the program is exactly as if that variable never existed.

 

It would be impossible to distinguish a program with that variable from one without.

 

So the Optimisation gives you the one without - because it saves both data & code space.

 

See: Nine ways to break your systems code using volatile - in particular, the section "What does a C program mean?".

 

EDIT

 

Typo - "never"

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...
Last Edited: Wed. Jan 27, 2021 - 05:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understand! It hit home when you made these statements 

 

.......the effect of the program is exactly as if that variable never existed.  

and 

It would be impossible to distinguish a program with that variable from one without.

 Oh Gawd more reading

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

So in the following should I or should I not see a value in simulator

 

thnaks

 

 

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

Docara wrote:

I swear it's harder learning 'compiler' than it is C 

 

You could, if you wanted to, write it in assembler from scratch!  S.

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

Docara wrote:
So in the following should I or should I not see a value in simulator

No, as you code gets optimized too:

UDR0 = 0x42*2;

so i and k are optimized away.  For debugging, use -g optimization level, it's not as aggressive and it may work better for you.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Docara wrote:
I swear it's harder learning 'compiler' than it is C 

Actually, it's all about understanding 'C'.

 

The all-too-common misconceptions about optimisation arise from failing to understand, or misunderstanding, what a 'C' program is actually about.

 

As  John Regehr  said in that linked article:

the C program can be thought of as a specification of desired effects, and the C implementation decides how to best go about making those effects happen

 

https://blog.regehr.org/archives...

 

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

And sometimes the implementation screws it up, and you're better off writing the machine code to start with. laugh  S.

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

and sometimes that paradigm does mean that 'C' is not the language to do what you need to - and your really should write it in assembler

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

This is interesting and a little confusing so unfortunately I have to plead the novice card and ask what might be going on or where do I start to look for my problem and more specifically where do I put the -g? 

 

So top clarify:-

I have a piece of C code from a manufacturers Application Note that was written for Windows and I need part of it to run on a MCU. Now I have reproduced all the relative windows functions that I need BreakCOM, WriteCOM, ReadCOM, SetBaudCOM and reproduced them to MCU equivalent Functions. I was able to read and write at various speeds to any USART port I wanted and detect serial data via ISR and interrogate the data. 

 

Then out of the blue my _delay_ms()_  just stopped working! When I tried to simulate my previous working code,  AS7 didn't step through the code cleanly but reverted to a disassembly listing at the end of a couple of functions, instead of return properly to the origianal calling function. I then extracted the most minimalist amount code I could and put it in a new project to try an debug what was going on. Still the same problem as above. (this is roughly the point I started posting here).

I have uninstalled reinstalled MS7, uninstalled AS7. Forced windows updates, uninstalled windows updates. I have recently uninstalled all and installed VS Code. I've put my expected received responses in an array commented out the UDR calls and it simulated as expected. I included Stdio.h and using printf I produced an output that was loosely in line (subject to a few minor issues) with what I would expect.

I commented out the printf and copied my code over to MS7. Simulation again started dripping off the end of functions etc. So my code works in VS code but not in AS7 or MS7.

It was working one day then didn't the next -literally! 

 

My code does not use any 'fancy' C 'stuff' - just delays, decisions, Switch-Case and I/O and one Serial Rx ISR (yes I used volatile)

 

What would you do in my situation? I don't have the money to buy £100 of microchip debug tools. The only thing I can think of is an ATmega328PB-XMINI board for a tenner but would this be enough?

 

So, where is my place of known good to build from? Is it a compiler issue, Hardware (AVR) or Software (AS7/MS7)

Thanks

 

Sorry for the rant and my life story 

 

 

Edit :- Don't worry found location - it was already set to -Og  (what confused me was -g instead of -Og)

Last Edited: Tue. Feb 2, 2021 - 02:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Docara wrote:
The only thing I can think of is an ATmega328PB-XMINI board for a tenner but would this be enough?

Almost certainly.

 

So, where is my place of known good to build from?

You said you had  BreakCOM, WriteCO, etc working - so build from there

 

out of the blue my _delay_ms()_  just stopped working!

You must have done something to break it.

 

This is where some sort of "version control" system is invaluable - even if you're just a lone hobbyist:

 

https://www.avrfreaks.net/forum/program-help-me-roll-back-older-versions-my-code

 

A common mistake with _delay_ms() is to forget the requirement that its parameter must be a compile-time constant.

 

Also, the Studio simulator runs vastly slower than real time, so simulating _delay_ms() takes forever - which can give the impression that your simulation has "died".

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

If you have a small project for one of the IDEs that can be built and that will demonstrate the issue you are seeing then unless it contains private/proprietary code ZIP it up and attach it here so we can try to replicate.

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

Docara wrote:
... and ask what might be going on ...
Uncertain or unknown (hypothesis, design of experiments, formal methods when required though relatively rare, intuition, experience)

Docara wrote:
... or where do I start to look for my problem ...
Where the problem isn't then move (unit tests, integration tests, divide the problem space)

Compiler defects are sometimes identified during unit testing; otherwise, one operates a debugger and such.

Docara wrote:
... and more specifically where do I put the -g?
Toolchain

Docara wrote:
Simulation again started dripping off the end of functions etc.
Stack frame clobbered?

Docara wrote:
What would you do in my situation?
Operate linters (I, a mangler of C), add asserts.

Docara wrote:
I don't have the money to buy £100 of microchip debug tools. The only thing I can think of is an ATmega328PB-XMINI board for a tenner but would this be enough?
Splash another tenner (logic analyzer)

Docara wrote:
So, where is my place of known good to build from? Is it a compiler issue, Hardware (AVR) or Software (AS7/MS7)

  • Windows 8.1 is the most reliable Windows
  • Visual Studio Code has GDB
  • fyi, AVR is in LLVM
  • there's a certified C compiler [though not for AVR, the issue may be in GCC front-end (parser) or middle (intermediate representation)]

 


scientific hypothesis | Definition, Formulation, & Example | Britannica

 

Compiler and Toolchain Options | Microchip Studio

[bottom]

Debug options
 

 

Adding Automatic Debugging to Firmware for Embedded Systems

 

Troubleshooting real-time software issues using a logic analyzer - Embedded.com

 

AVR Studio On Mac & Linux? | AVR Freaks

debugWIRE via USB UART | AVR Freaks

AVR LLVM released | AVR Freaks

CompCert - Main page

 

"Dare to be naïve." - Buckminster Fuller

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

Hi Just popped back to post an update

 

cli() & sei() seem to have now stopped working in simulator. 

 

I used to clearly see the 'I' flag in SREG register get set now I don't. If I omit sei() and put in cli() for debugging purposes if I manually set 'I' cli() does not clear it additionally if I put cli() inplace of my sei() and upload then my RX ISR still ruts on hardware.

 

Thank you al so much for the replies it is so appreciated.  So in order

 

awneil:-

You said you had  BreakCOM, WriteCO, etc working - so build from there

Correct I have reproduced these for my needs and they work.

 

 

out of the blue my _delay_ms()_  just stopped working!

You must have done something to break it.

OK what sort of things could break this - interrupts?  I did have cli() as the first line of main whilst I was setting up USARTs then when done configuring I then ran sei() before continuing. I thought perhaps cli() WAS messing with delays so I commented it out - but no change.

 

A common mistake with _delay_ms() is to forget the requirement that its parameter must be a compile-time constant.

All I have ever used was this     _delay_ms(2); 

I stepped through a search and replace using _del and manually replaced all my delays with _delay_us(2000); this worked for one build, simulate cycle then didn't work again. Changed back to _delay_ms(2); still didn't work.

 

Also, the Studio simulator runs vastly slower than real time, so simulating _delay_ms() takes forever - which can give the impression that your simulation has "died".

Yes I was aware if this. This 'hang' was when I first it delays didn't run because that 'go for a coffee' screen didn't appear. I have a basic logic analyser which also showed no delay in my serial data. On occasion when delays did some times work the they were wrong period. 

 

clawson:-

 

If you have a small project for one of the IDEs that can be built and that will demonstrate the issue you are seeing then unless it contains private/proprietary code ZIP it up and attach it here so we can try to replicate.

I am reluctant to because I think I have found a little niche I could use financially in the future. In the UK due to the lockdown the Government has pretty much decided to completely screw the economy in case someone over 80 dies. I am an electrician who is now out of work, who might be able to go self employed and start up again if I could get this code working.

 

I have had large swathes of my code working in an online C compiler site which is what is confusing me. But it is not suitable for attached hardware or is AVR pins  aware. Delays work there, I can use printf and display 'things' but not in MS7. I also had the same code working in Codeblocks when I cut and paste. I uninstalled CB in case it was causing my issues with MS7.

To be fair the 'falling' of the end of a function only happens in code I have copied over from an Application Note and have tweaked. It uses a recursive function and pointers soo yeah!

 

However if these sections are removed I am still left with delays not working and now (today) sei cli, not functioning as expected based on simulator or as seen on hardware - Global Interrupts disabled Serial ISR still fires.

 

 

gchapman:-

 

Operate linters (I, a mangler of C), add asserts.

I'm sorry I don't understand

... or where do I start to look for my problem ...

Where the problem isn't then move (unit tests, integration tests, divide the problem space)

 

Compiler defects are sometimes identified during unit testing; otherwise, one operates a debugger and such.

My functions worked (as seen on hardware and MS7 simulator) I've been adding, subtracting or moving code to try and find a pattern. I don't post to forums unless I'm completely buggered or it might be a quick clarification type of question

 

I don't have the money to buy £100 of microchip debug tools. The only thing I can think of is an ATmega328PB-XMINI board for a tenner but would this be enough?

Splash another tenner (logic analyzer)

 

Please look above at screen grabs - I have been using one

 

  • Windows 8.1 is the most reliable Windows
  • Visual Studio Code has GDB
  • fyi, AVR is in LLVM
  • there's a certified C compiler [though not for AVR, the issue may be in GCC front-end (parser) or middle (intermediate representation)]

 

If I had another box I could use / have Win7 or Win8.1  there would already be a clean install on it for comparison purposes and 'place of known good, fault finding

What relevance is 'Visual Studio has GDB' please explain

what is LLVM?

What relevance is a certified compiler in this situation? MS7 is used by thousands of people presumably without an issue- my problems have to be something I'm doing right?

 

It seems SO strange that after working on the same code for months, only moving forward to new function when the previous code works as anticipated, then one day bang problems!

 

(apologies if I have messed up responses to poster hope you don't take offence)

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

Docara wrote:
In the UK due to the lockdown the Government has pretty much decided to completely screw the economy in case someone over 80 dies.
As you get closer to 80 you may begin to learn that life is just as precious however old you are.

 

Won't be helping you again.

 

Have a happy life (while you can).

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

Docara wrote:
I'm sorry I don't understand
The C standard has a lot of ambiguities some of which are resolved as implementation-defined; a linter identifies usage of ambiguities and known defects (pattern matching)

Assertions make visible constraints and are one way to identify a possible defect in a file (or indirectly in an associated file) (defect -> fault -> failure)

Docara wrote:
What relevance is 'Visual Studio has GDB' please explain
Visual Studio Code has GDB extensions.

AVR GDB is another AVR debugger though mega2560 JTAG is "expensive" other than MPLAB Snap; MPLAB Snap's AVR GDB proxy is in atbackend.exe (Microchip  Studio 7)

Docara wrote:
what is LLVM?
LLVM is another compiler or interpreter backend; one of several LLVM frontends is Clang (C, C++, etc.)

Docara wrote:
What relevance is a certified compiler in this situation?
When a defect is evident via GCC and not evident via a verified compiler.

Docara wrote:
MS7 is used by thousands of people presumably without an issue- my problems have to be something I'm doing right?
Maybe not; defects in Windows 10 and .NET updates have caused Atmel Studio 7 malfunctions.

Defective PC DRAM will cause anomalies.

AMD CPU have ECC; Intel server CPU have ECC.

 


LINT

by Jack Ganssle

[mid-page]

But much more powerfully, lints can look at how multiple C files interact. ...

Adding Automatic Debugging to Firmware for Embedded Systems

 

MPLAB Snap | AVR Freaks

Microchip Studio 7.0.2542 | AVR Freaks

 

The LLVM Compiler Infrastructure Project

...

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

...

Clang C Language Family Frontend for LLVM

 

CompCert - Main page

 

Slow compiling - win10 update issue maybe? | AVR Freaks via Another Win_10 rant of frustration-part 2 | Page 3 | AVR Freaks

Atmel Studio 7.0 new install on Windows 10 2004 - not starting | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

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

Docara wrote:

MS7 is used by thousands of people presumably without an issue- my problems have to be something I'm doing right?

gchapman wrote:
Maybe not

But probably yes.

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

I'm sorry you feel that way

 

Both my parents died from Covid related complications this year and they were furious that "the country me and my friends died for" is being decimated and "run by fools" and that they couldn't hug their grand children for a year when they were well and able to do so. They were 88 and 93. The (last) big family Christmas that was planned didn't happen, we weren't allowed to travel to care for them when my mother had a fall, - so it was out-sourced to 'carers' who guess what carried the virus. Please don't lecture me about how life is precious I have lost more than I am prepared to say here - but have no illusion I KNOW LOSS and it's why I'm practical not sentimental about it - you see enough death you know life is about living. 

 

From Government statistics average life expectancy in the UK is 81. Average age Covid related deaths is 83.

STATISTICALLY they are trying to keep people alive longer than the STATISTICAL average natural death age. Should this be at the expense of everyone else's financial suffering? - Where is the money going to come from for benefits because everyone is out of work? Your grandchildren will be paying for this by having debt hanging over their heads or decades to come - great legacy. As you are, presumably, from the 'baby boomer' generation you know the fantastic opportunities you have had in your life, sad and selfish to think the same type of opportunities should not be afforded to the up and coming generation(s).

 

And yes I am very angry and bitter about what happened. Vulnerable people should have been protected. Whilst pubs, clubs cinema and the like should have been closed, we (young people especially) should have been allowed to acquire herd immunity to help protect the vulnerable by proxy (Swedish model) until a vaccine came along. Do not forget the reason we are going through this crap is "to protect the NHS" the same NHS that Government has robbed blind and underfunded for years so now they can't cope when a (long predicted) pandemic. We had a national bed occupancy rate of 95% before the pandemic how were we going to ever deal with a blip in the populations health so the country was closed!!! No official body has commented on the effectiveness of nasal antivirals (like Vicks First Defense) tablet based decongestants to limit sputum build up on the chest or even antihistamines as a preventative measure to stop the body over reacting to the infection if contracted. No proper instructions on how to use PPE - double gloving when in supermarkets discarding out pair when leaving,  using isopropyl alcohol to wipe all purchased item before bringing into the home etc etc etc so yes I'm angry!! 

 

Covid is NOT Ebola  - The current measures are not appropriate for 'flu with a chance of a chest infection' and yes I am being glib! Being alive and living is also about death and dying BUT ALSO being allowed to die with dignity all of which is being taken from us. 

 

Have a happy life (while you can).

F*** you!

 

I am currently waiting on the results of suspected (the family curse) Liver/ Pancreatic Cancer biopsy which, guess what, had to be postponed for 9 months because of lock down - it would be nice if I could see 60 let alone live to be in my 80's like you. More people have died through late diagnoses of cancer than Covid.  

 

Thank you for your help when you gave it - some of it was useful.