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) 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 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 register disabling the Pull-up resistor and enabling the Pull-down resistor, Enabling/disabling the Input buffer but nothing... the GPO0 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:
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
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
/*SPI transfer function*/
void SPI_send_tiny( uint8_t * buffer, uint8_t len)
Chip_SSP_WriteFrames_Blocking((LPC_SSP_T *)LPC_SSP0_BASE, buffer, len);
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) and it worked!