EasyEVSE 1060 to sigbrd2x interface issues

[chrisedwards]

This is a follow up to this post:

https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2...

Short synopsis: I have a RT1060EVKB/Sigbrd2x EVSE, and a RT1064/Sigbrd2x EV running v5.0.8 software that I’m trying to stand up.  This was originally posted as a response to the question above, but I wasn’t sure whether the tech reps followed up on the thread responses.

Thank you for your response.  I'm back working on this and am having issues getting EVSE code v5.0.8 that I got from NXP’s Git to work.  It builds fine and displays the GUI, but when I try to use its debug interface and request the version information, I get a correct response for the 1060 code of 5.0.8, but the version of the sigbrd2x shows as hw: v 255, and sw: v255.255.0.  I seem to recall reading a post somewhere that said there was some issue with a communications conflict with the LCD display on the 1060 board.  I can program the sigbrd2x and step code, so I'm pretty confident that that side is executing.  I'm using the EVSE-RT106X-CBL rather than the arduino headers.  My primary symptoms (besides the EV and EVSE sides not talking to each other) are the version reporting above that seems suspect, and I can't get past the "firmware download" status on the EVSE LCD, and the EVSE code on the 1060 won't start if the sigbrd2x is powered up (I'm powering them separately).  It feels like a communications issue.  Is there a patch / workaround for this?  If so, can you point me to documentation on how to resolve it?

Best Regards,

Chris Edwards

[Gavin_Jia]

Hi @chrisedwards ,

Thanks for your interest in NXP MIMXRT series!

It seems the RT1060 is reading an idle/pulled-up SPI bus and getting no valid data back. This means the RT1060 ↔ Sigbrd2x SPI link never established — which also explains why the EVSE stays at "firmware download" and why the two sides don't talk.

Suggested steps:

- Scope the SPI lines (SCK/MOSI/MISO/CS). If MISO stays high, the board isn't responding → confirms the 0xFF.
- Check the EVSE-RT106X-CBL wiring against the connector pinout in the signal-board manual — verify all SPI lines + GPIO are connected correctly.
- LCD vs. SPI pin conflict: Temporarily disable the LCD and re-read the version to isolate it.
- Follow the power-up order in the user guide, or power the host first.

Best regards,
Gavin

[chrisedwards]

Hi Gavin,

Check sigboard’s qspi flash:

              Powering the boards separately, I don’t see any traffic on the SPI pins of U17 (which is where I believe the switch gets its firmware).  I do see traffic on these pins on U17 of my EV setup (physically different board). 

Check sigboard’s host interface SPI:

              I don’t see any traffic on the spi pins of the host connector (19,21,23,24) when I have the 1060 powered and then apply power to the sigbrd2x (with the 1060 and sigbrd powered separately), nor when I power the sigbrd via the cable that goes to J32, with J2&J3 appropriately set).

From digging into the User Guide (UG10140):

I noticed that LEDs D18, D21, and D33 never illuminate.  They do on the sigbrd2x I have in my EV setup.  D24 does not illuminate on either setup.  D19 blinks.

End state of debugging steps, after disabling the GUI:

Ok with the LCD disabled by setting ENABLE_EVSE_UI to 0 in EVSE_config.h, the 1060 boots while connected to the sigbrd2x, using the cable that powers the sigbrd from J32 on the 1060, I can get a version number for the sigboard hw ( v2), and the sigboard sw v1.2.0. 

Still no traffic on sigboard’s U17 nor illumination on LEDs D18, D21, 24, or D33.  D19 blinks.  Still no activity on the SPI pins on the sigboard’s host connector.

So… progress, but it feels like the switch is not coming up at all. The user’s guide implies that the LEDs indicate that the switch isn’t working.

Thanks and Best Regards,

              Chris