AVR Freaks

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

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 

aaarrghh 

Typos and brain farts gentlemen - I feel suitably chastised!!!! (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.

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  

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;
}

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. 

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 

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

thnaks

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)

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)