CCo_Request

[Bhargava056]

Hello,

I am working with a RED-BEET board using a QCA7000 device in SPI.
I am sending a data in 8-bit order, to RED-BEET board,

Setup:

• Chip: QCA7000 (RED-BEET)
• Interface: SPI slave
• SPI mode: CPOL=1, CPHA=1
• Data width: 8-bit, MSB first
• CS held LOW for entire transaction
• INT pin connected and monitored
• Firmware: QCA7005_FW_1.1.0-02_lite
• PIB: SPI-slave PIB flashed using plctool and power-cycled.

Status:

• SPI signature read works correctly
• BFR_SIZE register can be read (not all 0x00 or 0xFF)
• SPI communication appears functional

Problem:

• Ethernet / HomePlug AV frames sent over SPI
• CC_CCO_APPOINT.REQ frame transmitted
• No response from PLC
• INT pin does not assert after frame TX

Frame details:
The data is

cleanTransmitBuffer(SPIEtherFrame->EtherFrame.MMEntry);
SPIEtherFrame->sof =  0xAAAAAAAA;
SPIEtherFrame->EthernetLength = 119;//
SPIEtherFrame->RVSD = 0x0000;
SPIEtherFrame->EtherFrame.DA =0xC4930059CBC6;
SPIEtherFrame->EtherFrame.SA= 0x010BB5000001;
SPIEtherFrame->EtherFrame.EtherType = 0x88E1;
SPIEtherFrame->EtherFrame.MMV=1;
SPIEtherFrame->EtherFrame.MMTYPE=MMType;
SPIEtherFrame->EtherFrame.FMI =0;
SPIEtherFrame->EtherFrame.FMSN = 0;
/*uint16_t mmEntryData[] = {0x01, 0x00, 0x11, 0x22, 0x33, 0x44, 0x33, 0x22, 0x11, 0x02,
                          0x2D, 0x37, 0x03, 0x02, 0x02, 0x6B, 0xCB, 0xA5, 0x35, 0x4E,
                          0x18, 0x01};

memcpy(SPIEtherFrame->EtherFrame.MMEntry,mmEntryData,sizeof(mmEntryData));
for (i=0;i<3;i++)
{
    SPIEtherFrame->EtherFrame.MMEntry[i+1] =(SPIEtherFrame->EtherFrame.DA >>(32-(16*i)))& 0xFFFF;
}*/
uint16_t mmEntryData[] = {0x00C4,0x9300,0x59CB,0xC600};
memcpy(SPIEtherFrame->EtherFrame.MMEntry,mmEntryData,sizeof(mmEntryData));
SPIEtherFrame->eol = 0x5555;

and the frame is sending like this

uint16_t Length =  128;  //data->EthernetLength +10;
uint16_t i = 0;

GPIO_writePin(PLC_SPI_CS_PIN, 0);
// telling QCA  that will give ethernet frame of length size
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (command >> 8)&0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, command & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (Length>> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, Length & 0xFF);

// telling QCA  that will give ethernet frame after this
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (WRITE_BUFFER >> 8)&0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, WRITE_BUFFER & 0xFF);
//SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (WRITE_BUFFER >> 8)&0xFF);

// this is actual Ethernet Frame
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->sof >> 24) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->sof>>16) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->sof>>8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->sof & 0xFF);



// Check Order
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EthernetLength & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EthernetLength >> 8) & 0xFF);

SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->RVSD >> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->RVSD & 0xFF);

SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.DA >> 40) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.DA >> 32) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.DA >> 24) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.DA >> 16) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.DA >> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.DA & 0xFF);

SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.SA >> 40) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.SA >> 32) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.SA >> 24) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.SA >> 16) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.SA >> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.SA & 0xFF);

//SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.EtherType >> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.EtherType & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.EtherType >> 8) & 0xFF);

SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.MMV);

SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.MMTYPE >> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.MMTYPE  & 0xFF);

SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.FMI);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.FMSN);

//SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.MMEntry[0]& 0xFF);
for(i=0;i<MMENTRY_SIZE;i++)
{
    SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->EtherFrame.MMEntry[i] >> 8)& 0xFF);
    SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->EtherFrame.MMEntry[i]& 0xFF);

}
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, (data->eol>> 8) & 0xFF);
SPI_pollingNonFIFOTransaction(spibase, PLC_SPI_DATAWIDTH, data->eol & 0xFF);
DEVICE_DELAY_US(PLC_SPICS_SAFTEYDELAY);
GPIO_writePin(PLC_SPI_CS_PIN, 1);, i did not getting any reply from the RED-BEET, 

Questions:

1. Is there a known working example of CC_CCO_APPOINT.REQ over SPI?
2. Are there mandatory PIB flags required for CC responses?
3. Any common reasons PLC ignores CC frames even when SPI is OK?

Any guidance would be appreciated.
Thank you.

[mhei]

I think, you don't need to bother with this kind of frames which are used - if I remember correctly - only for the PLC internal management. The module is running a firmware which handles all the low-level management stuff for you. I assume that the firmware is just not responding on the SPI interface for such frames.

[Bhargava056]

I think, you don't need to bother with this kind of frames which are used - if I remember correctly - only for the PLC internal management. The module is running a firmware which handles all the low-level management stuff for you. I assume that the firmware is just not responding on the SPI interface for such frames.

Thanks for the clarification.
So, to confirm my understanding: in the RED-BEET / QCA7000 SPI-slave firmware, CC_* management frames (such as CC_CCO_APPOINT) are handled internally by the PLC firmware and are not expected to be injected or responded to via the SPI interface.

In that case, SPI should only be used for data or supported vendor/application messages, while AVLN control (CCo selection, NMK handling, etc.) is done via PIB configuration and firmware logic.

Please let me know if this understanding is correct, or if there are any SPI-accessible management messages that are supported.

And also, can you conform that NMI key also handeled by internally by the PLC firmware, when i doing with spi.

[mhei]

In that case, SPI should only be used for data or supported vendor/application messages, while AVLN control (CCo selection, NMK handling, etc.) is done via PIB configuration and firmware logic.

Exactly. Once the module is part of an AVLN, then you can send and receive usual Ethernet frames via SPI which are passed transparently to all peers (considering the MAC adresses etc.). There are some vendor specific Ethernet frames (MMEs), see this project here, to query/control the QCA firmware. For example the tool "plctool" can be used to retrieve PIB file, set the NMK etc. Here you can have a look at the MMEs supported and the structure.

To put the module into an AVLN, just set all peers to the same NMK (using e.g. mentioned plctool), use push-button simple connect feature of the firmware or in case of electric mobility, this is handled by the SLAC process.

[Bhargava056]

In that case, SPI should only be used for data or supported vendor/application messages, while AVLN control (CCo selection, NMK handling, etc.) is done via PIB configuration and firmware logic.

Exactly. Once the module is part of an AVLN, then you can send and receive usual Ethernet frames via SPI which are passed transparently to all peers (considering the MAC adresses etc.). There are some vendor specific Ethernet frames (MMEs), see this project here, to query/control the QCA firmware. For example the tool "plctool" can be used to retrieve PIB file, set the NMK etc. Here you can have a look at the MMEs supported and the structure.

To put the module into an AVLN, just set all peers to the same NMK (using e.g. mentioned plctool), use push-button simple connect feature of the firmware or in case of electric mobility, this is handled by the SLAC process.

Can you tell where it defined, i check the documents, but they did not define like that.

Thank you for your reply

[adirschl]

Hi Bhargava,

for support regarding RED-BEET please open a ticket at plc@codico.com.
Then we can check if you have access to all necessary documentation

BR,
Andreas Dirschl
CODICO