atmega 128 doesn't return from a function even if Extended.M103C fuse bit is disabled

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

 

Hi I know i should n't be using atmega128 but it will take some time to replace besides there are 100's of PCB already in making. my problem is, if you look at the main()
i have declared each function just once , at first it seems like my program was never leaving the intialize_ESP8266() function because i had the TX of my 128 connected to 
arduino and i was seeing this on serial monitor

AT+CWMODE=3
BT+CIPMUX=0
AT+CWMODE=3
BT+CIPMUX=0
AT+CWMODE=3
BT+CIPMUX=0
AT+CWMODE=3
BT+CIPMUX=0
I dont understand where the problem exactly is a similar problem occured before but it was solved when i disabled the M103 fuse bit.

 


char AT_Command_Mode[]="AT+CWMODE=3\r\n@";
char AT_Command_Single_Connection[]="BT+CIPMUX=0\r\n@";

void Initialize_usart()
{
    UBRR1L=103;
    UCSR1B|=(1<<TXEN1)|(1<<RXEN1)|(1<<RXCIE1);
    UCSR1C|=(1<<UCSZ10)|(1<<UCSZ11);
}

void intialize_ESP8266()
{

    int Wifi_buffer_counter=0;
    while(AT_Command_Mode[Wifi_buffer_counter]!='@')
    {
        while(((UCSR1A&(1<<UDRE1))==0));
        UDR1=AT_Command_Mode[Wifi_buffer_counter];
        _delay_ms(10);
        Wifi_buffer_counter++;
    }
    _delay_ms(3000);
     Wifi_buffer_counter=0;
     while(AT_Command_Single_Connection[Wifi_buffer_counter]!='@')
     {
         while((UCSR1A&(1<<UDRE1))==0);
         UDR1=AT_Command_Single_Connection[Wifi_buffer_counter];
         _delay_ms(20);
         Wifi_buffer_counter++;
     }
     _delay_ms(3000);

}

void timer_initialization()
{
    TCCR0 = (1<<CS02)|(1<<WGM01)|(1<<COM01)|(1<<CS00)|(1<<CS01);
    OCR0 =50;
    TCNT0=0;
    TIMSK = (1<<OCIE0);
    sei();
}
ISR(TIMER0_COMP_vect)
{
    shift_out_data2(data,digit_number);
    digit_number++;
    if(digit_number==5)
        digit_number=0;
}

int main(void)
{
       DDRC=0b00111100;
       int number=0;

       Initialize_usart();
       intialize_ESP8266();
       timer_initialization();
    while (1)
    {

    }

}

 

 

Here are a few things that i tried  i put this chunk of code in different places of my code to see where my Instruction pointer was actually reaching

 PORTC &= 0b11011111;   //LED attached to pin 5 of PORT C
 _delay_us(1000);
  PORTC |= (1<<5);     // LED TURN OFF

 

The LEd turns on after several iteration of Initialize_ESP8266()  function and stays on and the USART stops it doesn't transmit anything the program looks kind of stuck for few seconds (with LED still on) and then goes back to the same iteration of ESP8266 function. Here i noticed that my ISR miracoulously starts working because i can then see digits on my seven segments. 

 

Then i tried putting this code between Timer intialize() function and intialize_ESP8266() function and it blinked for 1 second after every iteration of initialize_ESP8266  function as if these three function were in some kind of a loop.

 

Finally i tried putting this code inside my ISR (only the first line ofcourse without delay) and the led is on continuously but then as soon as i put some code in while() it stopped working

 

Does it make sense to anyone??? 

I have attached an image depicting the fuse bits ... i am using 16MHz oscillator 

Please help me any suggestion would be highly appreciated.. Thanks

This topic has a solution.
Last Edited: Fri. Apr 19, 2019 - 09:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1
 UBRR1L=103;

You should also initialise UBRR1H to zero just in case it wakes up with some other value.

 

edit

_delay_us(1000);

That's only 1ms, you reckon your eyes are fast enough to see the led coming on?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. Apr 18, 2019 - 06:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 i made both of the changes that you pointed out still the results are same.. i used the simulator and i found one more thing 

when i reach this step and press step into once it the leads me to while loop instead of going to _delay_ms(10);

 

 

Then if i press step into once again then it goes somewhere else in delay.h file  

to this step and if i press step into once again then i can no longer press step into the button becomes unpressable along with other debugging options

 

 

 

 

 

Last Edited: Thu. Apr 18, 2019 - 07:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

SufyanRaza26 wrote:
. i used the simulator

Because the simulator runs about 100x slower then the real thing, any calls to delay will take MUCH longer to run,

you have two choices, don't step into calls to delay, but use step over and go take a coffee/tea break, or

for debugging, use a much shorter delay!

 

From you problem description, it sounds like your AVR is resetting, check to see if your wdt has been enabled, perhaps from the fuse WDTON being set,

the default timeout for the WDT is about 16ms, or just enough time for your string to print out, then reset, print, reset,print.....

or your code is getting lost and wrapping around back to address 0 (reset) and restarting.  The simulator should help you spot this if that is the case.

 

Jim

edit: added reset

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

Last Edited: Thu. Apr 18, 2019 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

THis one has me a little confused:

 

while(AT_Command_Mode[Wifi_buffer_counter) !='@'

 

And later on you do this:

Wifi_buffer_counter++;

 

Do you have your buffer preloaded where in it somewhere the ASCII "@" is located and you just keep incrementing until you hit it?  What happens if the buffer/counter does not contain the "@"?  I suspect that this loop just, well keeps looping.

 

Right Side Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

jgmdesign wrote:
Do you have your buffer preloaded where in it somewhere the ASCII "@" is located and you just keep incrementing until you hit it?
  

   
Yes Look at the first two lines of my code . i have used "@" as a string terminator although i know there are more efficient ways to implement it but i am just stuck here. 

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

I removed all the delays from my code and then simulated it it got  stuck on           

   while(((UCSR1A&(1<<UDRE1))==0));

then I removed it too so my program would come to the end of intitialize_ESP8266 function after that instead of entering while it will go down to the last } and if itry to further step into it goes to assembly code ... its so confusing

 

Also i tried to enable and disable that fuse but still no effects :S

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

UCSR1B|=(1<<TXEN1)|(1<<RXEN1)|(1<<RXCIE1); enables the USART Rx Complete interrupt.
Do you have a handler for that interrupt ?

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

you mean the ISR?  USART1_RX_VECT? not right now but if i get over with this problem certainly i plan to have USART recieve something 

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

Enabling an interrupt and not providing a handler is a time-proven method to generate frustration.
Many modem-like devices will echo what they receive.

From an ESP8266 datasheet

Quote:
Notes: By default, UART0 will output some printed information when the device is powered on and is booting up.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not right now

Then turn off the interrupt!! As soon as you get 1 char in the micro will go crazy because you don't have anything to handle it.

 

You are turning on global interrupt inside the timer init so if the USART flag happens to be set you lose control of the micro.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Actually I have 2 links which which connects the RX TX pins to the controller's RX TX pins i have my TX pin shorted since i am transmitting where as my recieve pin is not connected to my controller so even if I recieve something my controller will not know that i am receiving anything.. but still i can create an empty ISR .... let me try this 

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

Thank you sir!!! it did solve my problem but i dont understand why It was necessary to create an interrupt handeler when that interrupt was not even occuring. 
 have a look at the diagram below this is how my MCU is connected to external USART connector on a board i had shorted only link2 so why was the RX interrupt creating problem.

 

 

Last Edited: Fri. Apr 19, 2019 - 10:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
you are turning on global interrupt inside the timer init so if the USART flag happens to be set you lose control of the micro.

Also can you shed some light on this i dont quite understand..

Thanks!!

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

Every time you enable an interrupt (most of the bits have "IE" in the name) then you MUST implement the ISR() to handle it. Otherwise when the interrupting event occurs the AVR will still jump to the vector but by default they are all set to go to a routine that does a JMP 0. You can read more about this in the user manual in the section about "catch all"

Last Edited: Fri. Apr 19, 2019 - 10:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

since the rx pin was not connected to a valid logic source, it floats and generates many transitions. This would cause the usart to interrupt. With no ISR, the code resets. So as Mr Clawson suggests, don't enable an interrupt source without a corresponding isr.

 

It's interesting that the OP now blames the M103C fuse for everything when it doesn't work.

Last Edited: Fri. Apr 19, 2019 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you! I got it now! 

Last Edited: Sat. Apr 20, 2019 - 10:27 AM