LwMesh on ATmega1284RFR2 (TO knaall)

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

Hi knaall,

 

Your post went into forum black hole after I've tried to split it from the main LwMesh thread.

 

ATmega1284RFR2 is binary compatible with  ATmega128RFR2 and ATmega128RFA1.

 

How do you know that radio is not working? Have you tried to debug your application? Where it gets stuck?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Fri. Oct 16, 2015 - 12:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your reply!

 

Ahaa, I thought I violated some rules and somebody deleted it...

 

I've downloaded the lw Mesh and opened the peer2peer project for the XplainedPro_ATmega256rfr2, I changed the target to atmega1284RFR2 and added a software timer via "hal" and toggled a HAL_GPIO_PIN with it and that works (the pin toggles when I run it on the MCU). As I wrote I've made two PCB's (according to the basic application in the datasheet) and set the APP_ADDR to 0 for one and 1 for the other. I also added the following;

void HAL_UartBytesReceived(uint16_t bytes)
{
  for (uint16_t i = 0; i < bytes; i++)
  {
    uint8_t byte = HAL_UartReadByte();
	HAL_UartWriteByte(byte);    // <-------------------- Added this line

    if (appUartBufferPtr == sizeof(appUartBuffer))
      appSendData();

    if (appUartBufferPtr < sizeof(appUartBuffer))
      appUartBuffer[appUartBufferPtr++] = byte;
  }

  SYS_TimerStop(&appTimer);
  SYS_TimerStart(&appTimer);
}

and hooked up both PCB via USB UART interface to my PC and tried to communicate between them without success. But I did get the echo back so I know that the UART works on both MCU's. I tried to "sniff" the 2.4 GHz signals with a spectrum analyzer but there was nothing. I even removed the balun and placed a 50 Ohm resistor between RFN and RFP and tried to find the signal but there were nothing.

 

I looked through the code and cannot find anything that seems obvious to change, this could of course be due to lack of programming experience and I apologize if that's the case... 

 

Best regards

 

 

P.s I attached my schematic in case you wanted look at it. D.s

Attachment(s): 

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

If you see an echo from the device and not the terminal program itself (no echo if device is not powered), then it is a good sign, your transceiver is clocked and appear to be functional at least in the digital domain..

 

First you need to check the value of req->status in the appDataConf() function. This will tell why TRX can't send a frame.

 

If you don't have a debugger, then just enumerate all values and toggle GPIOs or LEDs.

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

You won't see separate frames with a spectral analyzer, they are too short and far apart.

 

The schematic looks ok. Can you show your PCB layout and pictures of the assembled board?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

Good evening!

 

I've now tried the "Rcb128rfa1_ATmega128rfa1"-project that Atmel provided with the stack and now I see a clear spike at 2.423 GHz (with a separation of 2 MHz from device to device) and I immediately tried to communicate between my MCUs, but without success. The spike is constantly present for both MCUs though, even when I'm not  typing anything in the serial monitor which seems a little odd. As you said, the carrier wave shouldn't be there when i'm not trying to transmit anything.

 

Sadly, I do not know how to us the debugger properly, I'm sorry. But I did try to add structure req to the watch but the value appeared as an "unknown identifier". I found some threads here on AVR Freaks but it didn't help much (bug in atmel studio, revert to old version...). 

 

Instead I tried to toggle the PE7 pin (CLKOUT pin in attached schematic) at a couple of places in nwkDataReq.c by typing in the serial monitor:

 

void NWK_DataReq(NWK_DataReq_t *req) //-------------------- check
{
    PORTE ^= 0b10000000; 
  .
  .
  .
  //Rest of the code
}

static void nwkDataReqSendFrame(NWK_DataReq_t *req) //-------------------- check
{
    PORTE ^= 0b10000000; 
  .
  .
  .
  //Rest of the code
}

static void nwkDataReqTxConf(NwkFrame_t *frame) //-------------------- Not Toggling
{
    PORTE ^= 0b10000000; 
  .
  .
  .
  //Rest of the code
}

static void nwkDataReqConfirm(NWK_DataReq_t *req) //-------------------- check
{
    PORTE ^= 0b10000000; 
  .
  .
  .
  //Rest of the code
}

void nwkDataReqTaskHandler(void) //-------------------- check
{
    PORTE ^= 0b10000000; 
  .
  .
  .
  //Rest of the code
}

The pin toggled in every function that is followed by 

//-------------------- check

 

Further more I toggled the same pin in the appSendData() function (not at the same time of course) and it toggled.

I also noticed that the app did not try to send a new frame until the "acknowledge time out" occured...

 

Do you have any ideas of what could be wrong now? 

 

I've attached pictures and the layout. The PCB in picture IMAG1095 is generated from the same schematic but I've added some stuff (that should not interfering with the RF part, the extra stuff work as it should) but it's between these two I want to communicate. Also, the track from the MCU to the balun and antenna is not matched, but I should be under lambda/4 and I'm not trying to achieve any long distances at this stage, so hopefully it will be fine for now.

Attachment(s): 

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

You will have to figure out how to debug further. At some point you will have to write a real application, so this skill will be required.

 

nwkDataReqTaskHandler() is called in a loop, so it does not say much. What matters is what states of the state machine a reached.  nwkDataReqTxConf() not being called is not good, so you need to go deeper. You can probably skip the stack itself and go right for PHY layer, there is only one file.

 

The fact that there is some constant frequency is bad.

 

Where did you get this antenna design from? It looks rather unconventional.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

I agree with you, should learn how to use the debugger properly!

 

Now I managed to get some feedback from the req->status with the code below:

 

static void appDataConf(NWK_DataReq_t *req)
{
	
	if (NWK_SUCCESS_STATUS == req->status) {
		HAL_UartWriteByte('S');
		
	} else if(NWK_ERROR_STATUS == req->status) {
		HAL_UartWriteByte('E');
		
	} else if(NWK_OUT_OF_MEMORY_STATUS == req->status) {
		HAL_UartWriteByte('M');
		
	} else if(NWK_NO_ACK_STATUS == req->status) {
		HAL_UartWriteByte('A');
		
	} else if(NWK_NO_ROUTE_STATUS == req->status){
		HAL_UartWriteByte('R');
		
	} else if(NWK_PHY_CHANNEL_ACCESS_FAILURE_STATUS== req->status) {
		HAL_UartWriteByte('C');
		
	} else if(NWK_PHY_NO_ACK_STATUS == req->status) {
		HAL_UartWriteByte('P');
	}
}

While appDataReq.options set to request a ACK my function above indicates that status is set to NWK_NO_ACK_STATUS even with the receiving MCU powered up. When I try to send something a second time I do not get any information in the serial monitor, only the echo. When I do not request an ACK the MCU tells me that the operation was a success. But there's nothing showing up in the terminal for the other MCU and when I try to send another character it behaves as in the previous case.

 

Regarding the phy.c I (yes you guessed right) toggled a pin inside every function and this is the result:

 

void PHY_Init(void) // Runned once

void PHY_SetRxState(bool rx) //Runned once

void PHY_SetChannel(uint8_t channel) //Runned once

void PHY_SetPanId(uint16_t panId) //Runned once

void PHY_SetShortAddr(uint16_t addr) //Runned once

void PHY_Sleep(void) //Not runned

void PHY_Wakeup(void) //Not runned

void PHY_DataReq(uint8_t *data, uint8_t size) //Not runned

uint16_t PHY_RandomReq(void) //Not runned

void PHY_EncryptReq(uint8_t *text, uint8_t *key) //Not runned

int8_t PHY_EdReq(void) //Not runned

static void phySetRxState(void) // Toggles and again when i try to send another char but not a third time

static void phyTrxSetState(uint8_t state) // Called again when i try to send another char but not a third time

void PHY_TaskHandler(void) // Toggles every 58.6 us

Some of the behavior is obvious but I didn't wanted to leave anything out.

 

The antenna design is from the manufacturer of the miniature chip antenna which I use. The chemistry lab on my school where I make my PCB was just free for a little while so I had to finish my PCB design a little to fast so I didn't have time to match it properly but I thought, as I mentioned, since the track is shorter than lambda/4 should not suffer from any transmission line effects.

Do you think that this is wrong and that I'am having trouble because of this? I have already re-designed my pcb with a new antenna so I could make a new version tomorrow if that's the case.

 

Regards / Chris

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

PHY_DataReq() is what actually sends the data, so if it was not called, then it is something really strange. You need to trace back all that leads to a call of this function and see why it is not called.

 

It all looks really, really strange.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.