LPC4357 P6_1 as GPIO3[0] don't want to go low. What I'm doing wrong?

[lucalavecchia]

Hi community,

I'm currently working on a custom board based on the MCB-4300 (LPC4357 IDE: MCUXpresso) where the Cortex-M4 has to program two ATtiny48 over SPI.

So, doing a "preliminary test", I'm sending 4 bytes to the ATtiny (0xAC,0x53,0x00,0x00) and I'm expecting to get back: "0xFF,0xFF,0x53,0xFF".

To be able to program the first slave (or just to talk to it, in this "preliminary test") rather than the second one I need to bring his reset line (P1_4 as GPIO0[11]) low and then send the 4 bytes data over the MOSI.

After configuring the P1_4 (GPO high) I started the "preliminary test" (on the first slave) and it simply worked!

At this point, I decided to carry on with this test on the second slave too and, after configuring the P6_1 as GPIO3[0] exactly as I've done for the P1_4, the communication doesn't succeed...

The problem is definitely related to the reset line which doesn't want to go low!!

I tried several different configurations for this pin (even on a different board) such as writing manually the SFSP[6][1] register disabling the Pull-up resistor and enabling the Pull-down resistor, Enabling/disabling the Input buffer but nothing... the GPO0[3] is always in high state (and the weirdest thing is that going to read the register B96 tells me his status is LOW which is not ).

I checked several times this track on the PCB and there isn't anything which is holding this line high.

Any suggestion in what I'm doing wrong?

following the code:

/*initialization P1_4*/ 

Chip_SCU_PinMuxSet(1,4,(SCU_MODE_FUNC0 | SCU_MODE_ZIF_DIS | SCU_MODE_INBUFF_EN | SCU_MODE_HIGHSPEEDSLEW_EN)); //ATTINY_RESET_1 P1.4 as GPIO0[11]
Chip_GPIO_SetPinDIROutput((LPC_GPIO_T *)LPC_GPIO_PORT_BASE,0,11);//outPUT
Chip_GPIO_SetPinState(LPC_GPIO_PORT,0,11,true);//high

/*initialization P6_1*/ 

Chip_SCU_PinMuxSet(6,1,(SCU_MODE_FUNC0 | SCU_MODE_ZIF_DIS | SCU_MODE_INBUFF_EN | SCU_MODE_HIGHSPEEDSLEW_EN)); //ATTINY_RESET_2 P6.1 as GPIO3[0]
Chip_GPIO_SetPinDIROutput((LPC_GPIO_T *)LPC_GPIO_PORT_BASE,3,0);//outPUT
Chip_GPIO_SetPinState(LPC_GPIO_PORT,3,0,true);//high

/*SPI transfer function*/

void SPI_send_tiny( uint8_t * buffer, uint8_t len)
{
   Chip_GPIO_SetPinState(LPC_GPIO_PORT,3,0,false);//rese2 low

   Chip_SSP_WriteFrames_Blocking((LPC_SSP_T *)LPC_SSP0_BASE, buffer, len);

   Chip_GPIO_SetPinState(LPC_GPIO_PORT,3,0,true);//reset2 high
}

To be completely sure that the problem is related to the P6_1's wrong behaviour I've linked the second slave reset line to the P2_9 (GPIO1[10]) and it worked!  

Thanks

[lucalavecchia]

Hi Bernhard,

yes the P6_1 is disconnected from the UDA1380 CODEC and has the right mux function, because the board that I'm working on is a costumer board based on the KEIL MCB4300 ("based on" I mean we just used this EVB as example to draw our custom)

regards

Luca

[bernhardfink · Accepted solution]

I took an older DualCore Blinky project for the MCB4357 and modified it a little bit. It's for KEIL µVision5, can be compiled and debugged with the limited eval version. I added P6_1 as LED port and toggle it in line with other (real) LEDs. And it works fine.

• Use the project in the CM4 folder
• Compile and flash it to the MCB4357 board
• The 2 LEDs PD10 and PD11 are flashing
• The GPIO3[0] on P6_1 can be probed on pin 4 of the UDA1380

Regards,

Bernhard.

[lucalavecchia]

Hi Bernhard,

thanks for replying to me, but I've already checked the initialization and everything looks fine. Before to bring the GPIO3[0] low I checked the register SFSP6_1 and the "mode" bits are set as function0 (GPIO).

regards

Luca 

[bernhardfink]

Hi Luca,

so you disconnected P6_1 from the UDA1380 CODEC on the KEIL board?

This is an output from the UDA1380 and it could be that it's driving against the GPIO.

On the other hand ... you wrote, that you checked it "even on a different board"

Regards,

Bernhard.

[soledad]

Hi,

The issue that you are having it is that the AT Timy, needs to perform a Power On Reset Cycle, so this pin need to have a  Reset Circuit,  a resistor and capacitor to provoke the Reset,  we are not familiar with the ATTiny microcontrollers, so I suggest that you ask the people from Microchip regarding the Reset Cycle and reset conditions that need to be asserted, nevertheless I am pretty confident that the RESET it is always in the same state because the device it is not enter in the reset state.

Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[lucalavecchia]

Hi Soledad,

thanks for replying to me, but I think the problem is not related to the ATtiny because:

1. the "preliminary test" is working on the first slave;
2. I'm triggering an "External reset" on the ATtiny (An External Reset is generated by a low level on the RESET pin @ATTiny48/88 datasheet );
3. changing just the Cortex's port (ATtiny reset line on P2_9 instead of P6_1) the "preliminary test" worked.

Does anyone have problems like that on the P6_1?

Thanks for your help.

[bernhardfink]

On the KEIL MCB4300 the port P6_1 is connected to the UDA1380 audio codec.

Please check if in your board init functions this port pin is configured for I2S usage, overwriting your own initialization as GPIO3[0]. I don't see any reason why it shouldn't work as GPIO, except if it is not correctly configured.

Regards,

Bernhard.