You are not logged in.
Hello,
This is a question regarding initialization of the packet done reset register.
1) In the ofdm_Rx_mimo.c, in the mimo_ofdmRx_init function, we set the pktDone_reset register to 0x133, and then in the setOptions function (called from warpmac.c), we set it to 0x130. From looking at the model (ofdm_txrx_mimo/Packet_timing_control/Detection_Disable), to reset the rx_pktDetReset line, we need to reset the Det_disabled line, and it seems like its detecting a postive edge on bits 0 and 1 of that pktDone_reset register. Does the code assume that the register is initialized to 0? We are finding that the det_disabled line is staying high after executing the code as called in warpmac.c.
2) In ofdm_Rx_mimo.c, in the setOptions function, we set bits 4 and 5 based on the interrupt type. From the model (ofdm_txrx_mimo/Packet_timing_control/Detection_Disable), we see these bits to control det_disabled line. Could you please provide us information on how these two are correlated? From our vantage point, it seems like these shouldn't be related.
Thanks for any help you can provide.
Offline
I'll use the field names from the Rx_PktDone_Reset description in the register map.
The underlying idea of this register is to configure how the PHY handles interrupts for received packets. The user code can configure the PHY to assert the Rx_Int_goodPkt and Rx_Int_badPkt interrupt outputs independently. When enabled, one of these signals will be asserted for every received packet. The decision of good/bad is based on the packet's checksum calculation. The two interrupts are enabled by the EN_GOODPKT_INT and EN_BADPKT_INT fields.
If either interrupt is asserted, the PHY ignores any further packet detection until the user code clears the interrupt. This is the purpose of the SR latch in 'OFDM Rx/Packet Timing Control/Detection Disable'. The latch is asserted when either interrupt is asserted and cleared by the corresponding reset bit being written. The code must assert and de-assert the RST_BADPKT_INT or RST_GOODPKT_INT fields to clear the corresponding interrupt, thereby re-enabling packet detection.
In WARPMAC, the interrupts are configured to a default state in mimo_ofdmRx_init, then set to the desired state by the second argument to mimo_ofdmRx_setOptions. When an interrupt is asserted, WARPMAC processes the packet then clears the interrupt using mimo_mac2phy_PktAck().
Offline
On reception of any packet, good or bad, the function mimo_mac2phy_PktAck is called. From what I understand, this sends an ACK packet. Is there something in the PHY that prevents an ACK actually being sent out (based on your current state)? If not, I see us sending ACKs for every packet we see, even if we just got a replied ACK (ie ACKS being sent back and forth). Also, in initialization, we do the same thing as the function mimo_mac2phy_PktAck... therefore do we send an ACK on initialization?
Offline
mimo_mac2phy_PktAck doesn't send an ACK packet; it just signals the PHY that the MAC has copied a received packet from the PHY's packet buffer, which allows the PHY to safely receive another packet. ACK packets are generated in the user's MAC implementation. In CSMAMAC, for example, an ACK is generated in the receiveGoodPacket function, and passed down to WARPMAC (which then passes it to the PHY).
Offline
Ok, that makes sense. If that's the case, there should be no reason for us to see a packet transmission upon initialization through CSMAMAC, correct?
Offline
No, there is a dummy transmit cycle during initialization of the Tx PHY. The OFDM driver function mimo_ofdmTx_enable() raises and de-asserts the software transmit signal (bit 2 of the Tx_Start_Reset_Control register). This is a hack to work around the Tx PHY's control registers for monitoring whether a transmission is active or finished. We intend to clean it up at some point. For now, there's no harm in letting the PHY transmit once at init, given that the radio's Tx path isn't even enabled.
Offline