How to configure pins reuse in software

[johnsonyin]

There is a pin reuse, X0D10 (1C) is used as SPI_CLK and ADC_DATA0. while debugging, one issue always happened, and went to and looped here forever. which in InitPorts ( ).
#if (I2S_CHANS_ADC != 0)
for(int i = 0; i < I2S_WIRES_ADC; i++)
{
clearbuf(p_i2s_adc);
}
#endif
in xu208.xn, <Port Location="XS1_PORT_1C" Name="PORT_SQI_SCLK"/>
<Port Location="XS1_PORT_1C" Name="PORT_I2S_ADC0"/>

if set ADC_DATA0 to other pin (1N), no this issue happened.
How to configure pin reuse in software ? Thanks

project discription : when device power on, first read/write data from flash data partition, then fill it to iSerialNumber of usb descriptor and send it to host.

[larry]

The XN file entries are just descriptions. Think of them as preprocessor macros:

Code: Select all

#define PORT_SQI_SCLK XS1_PORT_1C
#define PORT_I2S_ADC0 XS1_PORT_1C

What's probably happening is that you've passed port 1C to the flash library, which attached it to a clock block, then you did your flash reading and library stopped the clock block. Port 1C remained attached to the clock block, which is now stopped. That will make any inputs on that port hang.

To make the port run and return ADC data, it needs to be attached to the I2S clock block and re-configured the way it happens in the InitPorts function.

Which part of the code are you exactly doing the flash reading from? Is it before or after audio initialisation?

[johnsonyin]

The XN file entries are just descriptions. Think of them as preprocessor macros:

Code: Select all

#define PORT_SQI_SCLK XS1_PORT_1C
#define PORT_I2S_ADC0 XS1_PORT_1C

What's probably happening is that you've passed port 1C to the flash library, which attached it to a clock block, then you did your flash reading and library stopped the clock block. Port 1C remained attached to the clock block, which is now stopped. That will make any inputs on that port hang.

To make the port run and return ADC data, it needs to be attached to the I2S clock block and re-configured the way it happens in the InitPorts function.

Which part of the code are you exactly doing the flash reading from? Is it before or after audio initialisation?

Thanks for your information, Larry!

it's before audio initialisation, I put flash reading code in the beginning of endpoint0( ). please check attached file. and would you please show me how to reconfigured it to I2S port?

[larry]

Maybe you could add a channel to hold the audio (I2S) thread until endpoint 0 has read the flash? Like this:

Code: Select all

endpoint0(..., chanend c_wait)
{
           read flash
           c_wait <: 0 // go!
}
audio(..., chanend c_wait)
{
           c_wait :> int
           InitPorts()
           while (1) {
                   ...
           }
}

You'll need to try it to see if the InitPorts goes far enough to correctly configure ports/clock blocks that have already been used.

Alternatively, you could read the flash from the audio task. Endpoint0 also accesses the flash, but only for firmware upgrade, and because it's in C, there shouldn't be any parallel usage checks to stop you.

[johnsonyin]

Maybe you could add a channel to hold the audio (I2S) thread until endpoint 0 has read the flash? Like this:

Code: Select all

endpoint0(..., chanend c_wait)
{
           read flash
           c_wait <: 0 // go!
}
audio(..., chanend c_wait)
{
           c_wait :> int
           InitPorts()
           while (1) {
                   ...
           }
}

You'll need to try it to see if the InitPorts goes far enough to correctly configure ports/clock blocks that have already been used.

Alternatively, you could read the flash from the audio task. Endpoint0 also accesses the flash, but only for firmware upgrade, and because it's in C, there shouldn't be any parallel usage checks to stop you.

it can work well, thanks for your help and support! Larry
c_wait <: 0 // go! will be changed to outuint(c_wait,0); right?


by the way, we find other way to fix this issue.
#define setcflash(a,b) {__asm__ __volatile__("setc res[%0], %1": : "r" (a) , "r" (b));}
setting setcflash(ports.qspiSCLK, XS1_SETC_INUSE_ON) after finishing flash read.

[larry]

Yes, you can do outuint instead of using the output operator. The difference is that outuint will leave the switch path between the two channel ends open. That only matters if you are going across tiles. There are four switch paths available between tiles. If four are open and you try to open a fifth one, the fifth one will block until there is a spare.

And yes, XS1_SETC_INUSE_ON will reset the port to its default settings. The QSPI clock block connected to it will be disconnected and InitPorts will no longer hang.