AT86RF231 with any Micro

Last post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I want to use AT86RF231 with an arm processor. Are threre librairies and code examples available somewhere or do i need to adapt code from avr examples?

Thanks for your advices and answers.

K777

:)

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

Have a look at the Atmel MAC sourcecode. It contains support
for SAM7 and probably also SAM3 (Atmel Cortex-M3).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

Thank you

i've downloaded it already and i will have a look now i know where to look. (there is for SAM3)

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

Well,
I understood i needed to use the PAL and TAL API functions and adapt it tp my µ.

Do you know if µracoli Libraries contains code for Cortex-M3?
If yes, what is better to adapt, Atmel MAC sources or µracoli Library?

Thank you :)

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

You might find some useful code at http://www.newae.com/tiki-index.php?page=15dot4sniffer which contains a SAM7s sniffer.

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

> Do you know if µracoli Libraries contains code for Cortex-M3?

Not yet. Axel has plans in his mind to eventually extend µracoli
to Cortex-M3 devices, but it hasn't been done yet.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

In my use of the AT86RF231 i see there are some problems if i don't use a (10k) pull-down on the SLP_TR pin ((the chip version can not be read in trx_init.c)).

Has someone encountered the problem already?

I didn't see in the code that SLP_TR should be configured with pull down and i didn't see it in the application schematics. Are there other pins that need such a configuration?

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

A 10 kΩ pull-down on SLP_TR won't do you good. If you put
the transceiver on sleep, the resistor will draw 300 µA!

The transceiver has some internal pulling, but this is only applied
during P_ON state. The idea is that the controller gets time to setup
its SPI interface properly, and once that is done, it can proceed
issuing the CMD_TRX_OFF command to the transceiver. Upon the
transition from P_ON to TRX_OFF, the internal pulling resistors will
be disabled, in the assumption that the controller's interface lines
will now take over full control.

There's only one potential pitfall I could see: if your controller
catches an unexpected reset, it will float its IO lines, leaving them
in an undefined state. However, as long as you don't need the
AT86RF231's CLKM clock to drive the controller (which is fairly
unlikely in your ARM case), nothing bad will happen, since it's always
possible to subsequently get the transceiver into reset once the
controller's SPI interface has been re-initialized.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

Thank you for this answer. It made me check my pin configuration and so on... and i found a mistake.
Now everything is working perfectly well for SLP_TR without this pull down.

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

I'm using the "TAL performance test example" and the hyperterminal to debug my code.
If someone can describe me the behaviour after choosing:
"(D) : Transmit a continuous wave pulse on current channel".
How this is normally ending? Is a timer ending the transmission? if someone can tell me one word about this.

Thank you

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

> Is a timer ending the transmission?

Yes, I can see a timer there in the sourcecode. If I'm not
mistaken, it's supposed to stop after 50 ms. That's why it
is called "continuous wave *pulse*".

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

Thank you, now it's stopped after 50ms when pushing (D). One more thing debugged!

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

One more trouble i have is for reading the voltage sensor, everything is ok if i'm writing 2 times the bit of 'pal_trx_bit_write'for example:

/* Check if supply voltage is within lower range */
    pal_trx_bit_write(SR_BATMON_HR, BATMON_LOW_RANGE);
    pal_trx_bit_write(SR_BATMON_VTH, 0x0F);
void pal_trx_bit_write(uint8_t reg_addr, uint8_t mask, uint8_t pos, uint8_t new_value)
{
    uint8_t current_reg_value;
  for(int i = 0; i < 2; ++i)
  {
/*here the for i added */
    current_reg_value = pal_trx_reg_read(reg_addr);
    current_reg_value &= (uint8_t)~(uint32_t)mask;  // Implicit casting required to avoid IAR Pa091.
    new_value <<= pos;
    new_value &= mask;
    new_value |= current_reg_value;
    pal_trx_reg_write(reg_addr, new_value);
  }
}

I fear it could hide more problems.
i don't know where it could comes from.
If anyone has an idea or a test for debug, it's welcome.

Thank you

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

i found the guilty one is

 current_reg_value = pal_trx_reg_read(reg_addr);

if i just double it:

 current_reg_value = pal_trx_reg_read(reg_addr); 
 current_reg_value = pal_trx_reg_read(reg_addr); 

everything is ok with doubling too, in bit register reading:

    ret = pal_trx_reg_read(addr);
    ret = pal_trx_reg_read(addr);

I already used this for updating trx status

tal_trx_status = (tal_trx_status_t)pal_trx_bit_read(SR_TRX_STATUS);
tal_trx_status = (tal_trx_status_t)pal_trx_bit_read(SR_TRX_STATUS);

thinking that was just a communication error that happened sometimes but it seems no.

I've looked everywhere in the pal_trx_reg_read, there is no error for me.

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

I'm afraid you might need an oscilloscope (better yet, logic analyzer)
to debug this.

Reading registers twice is not recommended. Beyond wasting time in
many cases, some registers (like IRQ_STATUS) change their status upon
reading it.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

thank you for your answer.

well, now i'm cleaning my RX register after each reading, i don't need to read twice registers.
Coming to a certain point, there was a shift between the previous answer and the current answer of my spi reading :? . The battery monitor reading is well working now.

However, now, i'm not able to get the TRx_IRQ_PLL_LOCK at initialisation. Answer to check if the PLL has been locked (addr 143) is always 0. And the trx_status is on PLL_ON (9). Does it just mean that the command 'pll on' is working or that the pll is locked?

When i go further and try to make a continous wave i well get the interrupt on the pin 24 and reading at addr 143 gives a nice 1. (Why here it's working and not at the initialisation)

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

> Answer to check if the PLL has been locked (addr 143) is always 0.

By default, the IRQ mask in the AT86RF231 is applied *before* transferring
the IRQ status bits into register IRQ_STATUS (0x0F), so you won't see any
of the IRQ flags there that has been masked off. (In other words: any flag
showing up there will actually trigger an interrupt to the MCU.)

In order to change this behaviour, you have to set IRQ_MASK_MODE (bit 1 in
register 0x04, TRX_CTRL_1) to 1. With "IRQ_MASK_MODE" enabled, the IRQ_STATUS
register will always reflect the internal status, and the mask is applied
between register IRQ_STATUS, and the actual IRQ output line.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

Thank you it's working

    /* clear PLL lock bit */ 
    pal_trx_reg_read(RG_IRQ_STATUS);
    /* Enable poll mode */
    pal_trx_bit_write(SR_IRQ_MASK_MODE, IRQ_MASK_MODE_ON); 
    /* Switch PLL on */    
    pal_trx_reg_write(RG_TRX_STATE, CMD_PLL_ON);    
    /* Check if PLL has been locked. */
    do
    {...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm now facing some troubles with pairing.

When i use the timeout values of 50ms for Tx and 200ms to wait for Rx, i can't reach the pairing menu.
When i try to use 200ms for Tx and 50ms for Rx, i quickly (in less than 10 trials) see the message "Peer device found".

However the local node is in 'Pairing_rsp_rec'. And the remote node stays in 'Wait_for_pair_conf' and never receives pairing response (and never display he's acting as a reflector).

any idea that could help?

it seems to me that app_rx_frame_cb_for_pairing() is called before tx_done_handling() which should allow the transmission

thank you

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

> any idea that could help?

Sorry, that's beyond my field of experience.

I suggest starting a new thread, with a subject that points to the problem
(so those knowledgable about it might catch it).

Do you have some kind of sniffer? Sometimes, seeing the frames exchanged
over the air helps understanding the application behaviour.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

thank you for your answer. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=119984&start=0 is open.

I don't have sniffer. I will have a look on what kind of sniffer i could use

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

> I will have a look on what kind of sniffer i could use

Just in case you don't know (even if it's partially a self-plug): the
µracoli project has firmware and support code to use any of its supported
boards as a sniffer backend, with Wireshark as the frontend.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.