ST7590 Power Line Communication chip integrated with a PIC18 microcontroller

Question

I am using the ST7590 chip for PLC purpose which integrates with an STM controller, but my company uses Microchip controllers. I have signed an SLA so I will not post or talk about the non-public information. The public info that I refer to is the chip datasheet and the design guide.

I have followed the design guide to the letter in the hardware apart from the STM chip being used, USB, SDC reader and the JTAG (but these are peripheral).

I am using the PIC18F45K40 to control the ST7590. The EUSART, 8MHz clock, Digital IO and Analog work on the PIC18.

In setup:

Enable Clock; 
Delay; 
PLC_RESET=0;
DFU =0; 
Delay; 
PLC_RESET=1. 

In main:

Set EUSART; 
If(CTS ==0) 
    // send the appropriate string of bytes through EUSART; 
Delay; 
If(CTS ==1) 
    // send the appropriate string of bytes through EUSART; 
//long delay and Loop.

I monitor the TX of the ST7590 with a Logic probe and get no response.

In the main loop, I have also tried toggling the DFU pin between sending strings of bytes.

The strings of bytes I send I have checked multiple times, but if they were wrong the chip would still send an error response. Therefore I can only assume that it is the chip's firmware that is damaged or lost; alternatively that it is not in the state to be sent commands.

I have also replaced the chip with a fresh one multiple times to make sure the firmware is working.

Do you have any suggestions?

I know I have given very little information, but my hands are tied and the support for this chip with a tertiary controller is limited.

Answer 1

I'm going to suggest a troubleshooting approach which I've used in similar situations. It might seem that this is going "the long way around", but it has the advantage of getting more help from the manufacturer, and so can be a shorter route to success in the end.

As I understand it, the ST7590 is usually controlled by an STM MCU (I assume STM32, as on their ST7590 evaluation board) and that is the only configuration where ST will offer support. So the approach is fairly simple, albeit at an up-front financial cost:

• Buy the manufacturer's supported configuration / evaluation board, using the ST7590 and appropriate STM32 MCU.

• Debug any problems when using the ST-supported STM32 firmware on that hardware. ST should support you during this stage, since you make sure that the combination of ST7590 + STM32 would be their standard & supported configuration.

• Once that is working, you reverse-engineer the interface between the STM32 and ST7590, using an oscilloscope, logic analyser etc. Completely characterise the signals, commands, timing, responses etc.

• The result of that reverse-engineering exercise then becomes your blueprint for what you must duplicate in your PIC18 design.

• At that stage, if your PIC18 design doesn't work correctly, then there must be differences with the STM32 board's behaviour - find and fix them, looking at the blueprint of correct behaviour that you created earlier. It seems that you won't have ST's help for this last stage of ST7590 + PIC18, but you just keep referring back to the supported ST7590 + STM32 configuration to see how things should work.

  You could even use hybrid design steps e.g. that 8MHz clock which you intend to supply from the PIC18 in the final design, could indeed be supplied from a PIC18 (which is doing nothing else) while the main code still runs from the confirmed-working STM32. If that PIC18-provided clock is enough to stop the ST7590 + STM32 board from working (where the only unusual part is the PIC18 providing the clock) then you have identified this as a definite problem to investigate, before migrating all the code onto the PIC18.