ATTINY404 code stop running midway

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

Hi AVR gurus,

 

I am currently developing a system using ATTINY404 with LoRa. When i run my code the debugger did not continue to the next function and stop running. Using ATMEL ICE debugger i did see that it complete the previous function and when i continue stepping through it went into NOP. 

 

I run the optimization with optimize for debug and observe that the file size is still sufficient

 

Program Memory Usage     :    1366 bytes   33.3 % Full
Data Memory Usage         :    10 bytes   3.9 % Full

 

I'm puzzled why did not move to the next instruction.  From the code below it just freeze after function LoRa_Send. SPI analyzer confirm that there is no activity after that. I'm attaching the list file here

What should i do to trace the problem here? Appreciate the feedback from all the experts here

 

<while (1) 
    {                            
        uint8_t status = LoRa_Receiving();
        if(status == 1)
        {
            LoRa_initSend();
            LoRa_Send(ACKMessage,    sizeof(ACKMessage));
            LoRa_sleep();
            _delay_ms(1000);
            LoRa_initSend();
            LoRa_Send(NAKMessage, sizeof(NAKMessage));
        }
    }>

 

Attachment(s): 

This topic has a solution.
Last Edited: Sat. Apr 9, 2022 - 11:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The CPU will almost certainly not have stopped running. It probably hasn't returned correctly from the LoRa_Send function.

 

My guess is stack corruption in LoRa_Send.

Do allocate local strings or buffers in  LoRa_Send ? If so, ensure you do not write beyond their array sizes.

 

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

thanks WinterBottom. i'm passing arrays from main.c to the function along with it sizes.  

It should not exceed 11 bytes but i allocate 255 bytes for the payload. Is this overallocation giving a problem?

uint8_t NAKMessage[] = {0x4E, 0x41, 0x4B};
uint8_t ACKMessage[] = {0x41, 0x43, 0x4B};

 

void LoRa_Send(uint8_t payload[], uint8_t payload_length)
{
    uint8_t data[255];
    uint8_t length = payload_length + 8;
    
    data[0]        = 0x27;            //LORA protocol marker
    data[1]        = ID[0];
    data[2]        = ID[1];
    data[3]        = ID[2];
    data[4]        = ID[3];
    data[5]        = 0;            //count
    data[6]        = payload_length;
    data[7]        = 0;            //checksum: 0xEC
    
    for(uint8_t j=0; j <payload_length; j++)
    {
        data[j+8] = payload[j];
    }
        
    uint8_t checkSum = LoRa_calcCheckSum(data,length);
    data[7] = checkSum;

    //beginPacket
    //explicitHeaderMode
    RFM95_readReg(REG_MODEM_CONFIG_1);
    RFM95_writeReg(REG_MODEM_CONFIG_1,  0x72);
    // reset FIFO address and payload length
    RFM95_writeReg(REG_FIFO_ADDR_PTR, 0);
    RFM95_writeReg(REG_PAYLOAD_LENGTH, 0);
    
    // write data
    uint8_t currentLength = RFM95_readReg(REG_PAYLOAD_LENGTH);
    
    // check size
    if ((currentLength + length) > MAX_PKT_LENGTH) {
        length = MAX_PKT_LENGTH - currentLength;
    }
    for (uint8_t i = 0; i < length; i++) {
        RFM95_writeReg(REG_FIFO, data[i]);
    }
    
    // update length
    RFM95_writeReg(REG_PAYLOAD_LENGTH, currentLength + length);
         
    // put in TX mode
    RFM95_writeReg(REG_OP_MODE, MODE_LONG_RANGE_MODE | MODE_TX);
    
    while ((RFM95_readReg(REG_IRQ_FLAGS) & IRQ_TX_DONE_MASK) == 0) {
        _delay_ms(1);
    }
    // clear IRQ's
    RFM95_writeReg(REG_IRQ_FLAGS, IRQ_TX_DONE_MASK);
}
 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
uint8_t data[255];

 

You are trying to make an array on the stack that is 255 bytes in size, when you only have 256 bytes of ram total. The stack pointer gets moved down by (at least) 255 when you do that, so that array starts somewhere below a ram address. What the debugger does or what your code does when using those invalid ram addresses, I do not know, but it will not be good in any case.

 

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

brilliant, curtvm. Once i revise the allocation to 100 instead of 255 it works as expected. Thanks everyone 

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

Write the 8 bytes of your header (only need 8 bytes of stack), then write the payload- 2 separate loops of write. No need to copy payload from ram to ram first.