GPIO control using DIO doesn't works

[sobo]

Hello,

We start to develop our SW with the eval board for S32K358 and it's works fine, now we used our HW board.

We are able to used the CAN, the SPI but we are not able to set GPIO to 1 or 0.

This works fine on the eval board ( we are able to turn ON/OFF the led) but on our board it doesn't works.

We try several output, we set the output on INOUT and when we set the GPIO to 1 we read 0.
We have review the port ant DIO config several times.

We aren't able to understand why.
Do you have some suggestions on what to check ?

thanks you

S32K3 

[dduminy]

Good news : I managed to drive the pin in GPIO mode. In fact, the TSPC was not clocked. When it is clocked, the pin can be driven. So there is a kind of dependency between TSPC and some GPIO pins.

[PetrS]

Hi,

good point...IOMUX excel file shows MCU port and TSPC assignment in "TSPC Selection" tab, and 
the RM points to have TSPC clock enabled... 

PetrS_0-1709556675439.png

Seems I overlooked that. But TSPC clock should be enabled upon reset, that's why Radek was able to control pin after main function was hit.

BR, Petr

[dduminy]

Hello NXP Guys,

I think that the note is wrongly placed. Indeed, we didn't implement the TSPC feature, only the SIUL2. So I think moving (or copying) this note from TSPC chapter to SIUL2 chapter will help other customers.

Best regards,

David

[sobo]

hello @PetrS 

We done some more tests, on the eval board S32K3X8EVB-Q289, We are not able to set/reset the GPIO PTD21 but we are able to control the LEDs pin (PTG29,PTG30,PTG31,PTF21,PT22,PTF23) , so I think we know how to configure the DIO/port module (we are using EB tresos)

Are you aware of some errata on S32K358 ?

[PetrS]

Hi,

PTD21 is normal pad, connected to board's arduino headers, there would not be issue with GPIO functionality. Check MSCR117 for a setting. You can try GPIO input as well, just clear OBE and set IBE, apply high/low level on pad and check GPDI117 if values is changed.

There is no errata for SIUL module.

BR, Petr

[PetrS]

Hi,

for DIO usage you can refer to RTD demo example, but you probably did it.

Then I can recommend to check SIUL2 setting within debugger. To control GPIO pin it is enough to set respective MSCRn register to have OBE bit set and SSS=0. Then writing to given GPDOn register you control output level. It is assumed SIUL module is clocked, but if you are able to work with CAN, SPI then SIUL2 config is possible.

BR, Petr

[sobo]

Hi @PetrS 

we have check the register all is OK, but on the pin we can't read a '1', level high.
see attached screenshot.

cc0138fd-4784-4996-9e89-68184d066291.jpg

96ade014-dfaf-4fac-accf-d7c9ce65b8ff.jpg

[PetrS]

Hi,

this looks correct, not sure why you do not see it on the pin/header. So assuming you really measure right pin, I can only recommend to do below checks...
- set OBE and IBE with SSS=0, change GPDO and measure pin ouput and GPDI register
- set only IBE, and enable internal weak pull/down, see GPDI. connect pin externally to high/low, see GPDI
- set pin for available peripheral, i.e. eMIOS and generate some output, can be eMIOS GPIO output mode

BR, Petr

[dduminy]

I tested the GPD21 using the LCU0_LCU0_OUT4 function and I was able to generate the expected signal so only the GPO is impacted by this issue

[PetrS]

Hi,

so you tested that GPIO input is working, peripheral can drive the same pin, but GPIO output control using GPDO does not work. Really weird. Radek proved GPDO works properly. You can try to test PGPDO register, but assume it will be the same.

Then, please share very simplified project showing the issue so we can test it on the EVB.

BR, Petr 

[dduminy]

Hi Petr and Radek,

Yes and I tried on 2 different S32K3X8EVB-Q289 evaluation board and on our ECU prototype. I have always the same results. On the first evalboard, there was nothing connected except the trace32.

If you managed to drive this pin, it means that we have a software issue somewhere but I don't see it.

Perhaps, Radek can share his project as it is already done and I can test it instead of building a simple project for you ?

Best regards,

David

[dduminy]

When I apply a high level on the PIN GPD21 set as an input with pull down, I can see that GPDI117 is read as high level.

When I apply a low level level on the PIN GPD21 set as an input with pull down, I can see that GPDI117 is read as low level.

When I apply a low level level on the PIN GPD21 set as an input with pull up, I can see that GPDI117 is read as low level.

When I apply a high level level on the PIN GPD21 set as an input with pull up, I can see that GPDI117 is read as high level.

So, the GPD21 behaves correctly when it is used as input

[dduminy]

Here are the screenshots of the 3rd test :

dduminy_0-1709288692557.png

dduminy_1-1709288757328.png

dduminy_2-1709288804774.png

The level of GPD21 pin is low (0V)

[dduminy]

Here are the screenshots of the 2nd test :

dduminy_0-1709235446014.png

dduminy_1-1709235498339.png

dduminy_2-1709235548923.png

The GPD21 pin is in high state (around 5V)

[dduminy]

Hello Petr,

I works with Sophie. Here are the screenshot of the first test

dduminy_2-1709234872719.png

dduminy_1-1709234812984.png

dduminy_0-1709234765529.png

The PTD21 remains in low state (0V)

[RadekS]

Hello dduminy,

That is very strange.

We tried the same test on the same setup (S32K3X8EVB-Q289, the same MCU maskset, and the same manufacturing batch).

RadekS_0-1709296166524.png

We restart MCU and wait at the breakpoint at the beginning of the main() and drive the pin directly by Lauterbach probe. We measured voltage at PTD21 pin at J357 connector and also on GPIO pin matrix breakboard. 

RadekS_1-1709296334845.png

The output voltage fits with the pin output level and the same levels was detected at the pin input.

RadekS_2-1709296472730.pngRadekS_3-1709296503067.png

Are you sure that you do not have any load/short externally connected to the PTD21?

RadekS_4-1709296868466.png

Best regards

RadekS