stop_clock hanging.

[babazaroni]

What reasons are there for stop_clock hanging while trying to stop a clock block?

spi_slave_shutdown is hanging trying to stop the clock. If I ground the external pin it is connected to, stop_clock returns. There must be a way around this.

[richard]

What reasons are there for stop_clock hanging while trying to stop a clock block?

As documented here stop_clock() pauses until the clock is low. If the clock isn't running then this could pause forever. You can turn off a running clock so just taking out the call to stop_clock should fix this. I've patched the SPI slave component here:

https://github.com/xcore/sc_spi/pull/5

[xsamc]

I've patched the SPI slave component here:

https://github.com/xcore/sc_spi/pull/5

Richard's fix has now been merged into the master branch.
I've also updated the shutdown function of the SPI master module, to avoid any similar issues arising with it.

[babazaroni]

Thanks, that fixes the hanging problem.

But, it appears spi_slave_shutdown is not completely returning the resources to a neutral state.

I am using the MC reference board to connect to a sharc evaluation board, and using spi to boot up the sharc board. This only needs to be done once at power up, so I use the codec pins as spi pins, and after sharc boot then configure them as codec pins. I get a resource violation when I call ConfigAudioPorts.

The particular violation involves the miso pin, which is shared with the codec sclk pin. With the idea of sharing pins, is there anything else spi_slave_shutdown can do to return the pins back to a reset state?

I can provide more info and code if necessary.

[richard]

It looks like spi_slave_shutdown() turns off the ports. If you try and use them again without turning them back on you'll get an illegal resource exception. Try calling set_port_use_on() (from <xs1.h>) on the miso port after spi_slave_shutdown().

[babazaroni]

Thanks, that fixes the resource violation.

But now the audio io has a problem. This happens by just calling spi_slave_init() and spi_slave_shutdown() and calling set_port_use_on() for the 4 pins. So the spi code has some side affects still.

I'll try to narrow it down.

[babazaroni]

It's been a bit of a tedious process to return the state of the pins used by spi_slave to a state from which they can be properly configured by ConfigAudioPorts to work with the codec.

Here are some statements from spi_slave_init which I have needed reversed for the audio to work:

1. configure_out_port(spi_if.miso, spi_if.blk, 0);
reversed by:
configure_in_port(spi_if.miso, spi_if.blk);

2. set_port_slave(spi_if.mosi);
reversed by:
set_port_master(spi_if.mosi);

3. set_port_slave(spi_if.miso);
reversed by:
unknown. set_port_master(spi_if.miso) does not work

I've been just guessing and this has worked for items 1 and 2, but not 3. These functions appear to be doing a number of setc operations on the specified pin. If I knew what these setc operations were, I could work out the reversals more logically.

Is there a function that can return a pin to the reset state?
Where is the source code for the set_port_xxxx functions?

[richard]

Is there a function that can return a pin to the reset state?

Calling set_port_use_on() resets the port to it's initial state. Note that you can call this on a port that is already on, you don't need to turn it off first.

Where is the source code for the set_port_xxxx functions?

The the set_port_xxxx functions are implemented using compiler builtins. As such there is no xC / assembler source to look at. The majority map to a single xCORE instruction, so you can look in the architectural manual for an instruction that does the same thing. Often the instruction is mentioned in the doxygen documentation as well (for example set_port_master() maps to a setc instruction with the operand XS1_SETC_MS_MASTER).

[babazaroni]

I am experiencing these difficulties also with trying to read the spi prom, before configuring the audio ports.

In the DJ board, some of the spi pins used to read the spi prom are also used for the codec.

If I call flash_cmd_enable_ports followed immediately by flash_cmd_disable_ports, the audio will not run.

In fact, if I only call setc(p_flash.spiMISO, XS1_SETC_INUSE_ON), the audio will not run.

[babazaroni]

OK, I think I've figured this out. Since the flash spi and codec share the same pins, once you are done with flash access, you need to reset the codec ports, by calling set_port_use_on on them. ConfigAudioPorts does not do that, assuming the pins and ports have not been used by another function.