I'm developing mcr20a with stm32 MCU.Here comes some questions:
1.With mStatusAndControlRegs[PHY_CTRL2] &= ~(cPHY_CTRL2_RXMSK) . No RXIRQ Interrupt will get while the packect sniffer got a lot frames.
2. SEQ_STATE is NOT detailed described in Reference Manual( chapter. 9.2.37 in pdf )
3.How to deal with RX sequence while I want to start a TX seq. Is there a flag to check if RX seq is getting a part of the frame ?
4.If RX seq is NOT Started , all frames coming will lost ?
1. After unmasking the RX IRQ from the mStatusAndControlRegs[PHY_CTRL2] global array, you must synchronize that change with the XCVR through SPI to take effect:
3. You can find a similar check in PhyStateMachine.c file:
/* Check for an Rx in progress. */
uint8_t phyReg = MCR20Drv_DirectAccessSPIRead(SEQ_STATE) & 0x1F;
if((phyReg <= 0x06) || (phyReg == 0x15) || (phyReg == 0x16))
/* XVCR is receiving a packet */
4. If RX sequence is not started the XCVR is Idle and no data will be received.
Thanks . More Questions:
1.RX_IRQ should be a flag of buffer Recive Completely，Can I use it to capture a frame instead of RX_WATERMARK flag?
2.What exact mean of MCR20Drv_DirectAccessSPIRead(SEQ_STATE) & 0x1F <= 0x06 Or == 0x15 Or == 0x16 ? What about other values?
Is there a value of TX State ,or CCA State ?
Show me all the means exactly,please.
3.Since RX seq is allways required while No Frame to Send, how much time should it take to Wait for RX seq ?
I set 4ms to T3CMP to Abort RX seq automaticly, but not sure 4ms is enough or too short. Any suggestions ?
Waitting for Respone..
1. Yes, the RXIRQ flag or SEQIRQ flag can be used as a notification of a complete packet reception, after a RX sequence was armed in PHY_CTRL1.
2. The detailed description of the SEQ_STATE register is not public information.
3. RX seq is required only when the device needs to receive data.
The maximum Over-the-Air duration of an 802.15.4 packet, including ACK is ~5ms.
So you need to have at least 5ms remaining from the moment the 802.15.4 preamble was detected, until T3CMP will abort the sequence.
For example, if you have 1ms remaining until T3CMP will end the sequence, and you start receiving a packet of 2ms duration, the packet will NOT be received!
Also, stopping the RX sequence and restarting it asap, will cause the radio to go thorough warm-down, idle and warm-up, which will cause a "blind spot".
If you have too many "blind spots", you may loose the preamble and effectively the entire packet.
Thanks to your help,I succeed tranplanted an OpenSource Stack into MCR20A with STM32F207 !
A RFD can jion the COORDINATOR ,and transmit playload to each other. Somehow, the network is not robust enough or stable enough for daily use. Here comes some more Questions.
1. How could the SEQ_STATE register be not public,while the MCR20A chip is on sell and welcomed to use. It's NOT a private Stack ,it's JUST a register !
I assume SEQ_STATE to be :RX_BUSY 、TX_BUSY、RX_OFF 、RX_ON、 TRX_OFF、CCA_BUSY ...etc.
How can I check out the state to be RX_OFF(ready for TX or Retry RX ,but not in idle) ,which is a state can start a TX or RX without warmup the radio .
2. T3_TIMEOUT will abort RX or TR seq , will this aborting set radio "go thorough warm-down, idle and warm-up" ?
3. if "Quesetion 2" is yes ,how to abort the RX or TR seq without "go thorough warm-down, idle and warm-up" ? Is there a perfect way to transfer
the RX or TR to a TX ?
1. The SEQ_STATE reflects the states of the hardware's internal state machine, which is not public.
If you are in RX, you cannot start a TX/TR without going trough the Idle state.
You must abort the current sequence (RX), and then program the new sequence.
The radio will always do a warm-down and warm-up again when switching the active sequence.
If you need to find out the current state of the radio, just read the XCVRSEQ of the PHY_CTRL1 register.
2. The abort procedure will warm-down the radio and place it in Idle state.
The warm-up only happens when a new sequence (besides 0 - Idle) is programmed.
3. You cannot abort RX or TR without going thorough warm-down and Idle.
The only way to do this is to abort the active sequence, and then program the new one.
You can use the code provided above to check if the radio is receiving a packet before aborting the sequence.
I'm now tring to use ASM in MCR20A. But it failed of SELFTST . And I tested on three boards ,none PASSED . Also I tested AES data CRYPT ignore the failure of SELFTST , but none DATA retruns.
Here is my steps:
1. ASM_CTRL1 =1<<5 ; //ONLY selftest is on
2.ASM_CTRL1=1<<1 ;// LOAD_MAC is on
4 Wait for ASM_IRQ or Wait for ASM_CTRL2_LOAD_MAC
ASM_CTRL2_LOAD_MAC is Zero ,and no ASM_IRQ . This truns out SELFTST failed.
ASM_IRQ is Zero , i tried step7 ASM_DATA is Zero too.
Don't know Why , help me please.
To be able to use the ASM module of MCR20A, make sure the radio is not in a low power mode (for example AUTODOZE bit set in PWR_MODES).
Also, the self test does not assert an ASM_IRQ. The test takes exactly 3330 cycles to complete. You must wait for 3330 MCR20A cycles after the self test was triggered before reading the TSTPAS bit.
If the self test failed, the ASM module will disable itself and it cannot be used!
Follow these steps to enable the ASM module:
1. Enable ASM clock, and disable low power mode (if enabled): PWR_MODES = 0x19
2. Set SEFLTST bit of ASM_CTRL1 register
3. Set the START bit of ASM_CTRL1 register
4. Wait for 3330 clock cycles for the self test to complete (~105us). For example:
start_time = EVENT_TMR; //16us resolution
current_time = EVENT_TMR;
if( ((current_time - start_time) & 0x00FFFFFF) > 8 )
}while( !(ASM_CTRL2 & TSTPAS) );
Thank very much!
It finally passed the selftest.And I run a CBC encryption, the result data is as respected.
But somehow I CAN NOT Decryption the data. Can you tell me how to run a CBC decryption ?
The ASM module of the MCR20A is optimized for the 802.15.4 use case. You cannot perform a CBC decryption using this module.
The 802.15.4 uses CCM* where CBC is used to generate the MAC (Message Authentication Code), and CTR mode for the payload encryption/decryption.
Recently I found a strange problem: coordinator do not send ack rightly.
Here is the sniffer data.
A RFD with addr 0x1699 was sending data in a period of 2 seconds.
The coordinator got the data and supposed to send an ACK automaticly, but sometimes it didn't .
I checked the coordinator state is RX_SEQ ,and always is SEQ_STATE=20(dec). Don't know why it did not send ACK.
With this problem a lot of data will be discarded.
To send automatic ACK, the MCR20A must be configured to do so.
The device must have the MACPANID, MACSHORTADDRS and MACLONGADDRS registers setup correctly, so that the Packet Processor will not filter the incoming packet, and the AUTOACK bit of the PHY_CTRL1 register must be set.
But keep in mind that if the PROMISCUOUS bit of the PHY_CTRL4 register is set, then no ACK will be sent!