The datasheet is spectacularly bad at explaining how to send data back to the cc40 (or other HexBus master). So, here it is:
When the master is sending, it holds BAV low, as expected.
When it finishes, it watches for line activity (or a timeout).
If a data line or HSK line falls, it brings BAV high. If it then noticed BAV high, it gives an immediate error.
The trick is to bring BAV low on the slave side, bring HSK low, then bring BAV high (which it *kinda* talks about in the datasheet, but makes it sound like that is the work needed to call the master and then you can send your entire set of data. In reality, you have to go through the above for every nybble).
This is what I learned from the specification:
HSK is the handshake signal for nibble transfer. It is operated for every single nibble.
BAV is one layer higher. It indicates a master-slave interaction. It is pulled low by the master (unless there are specific requests to the master) and kept low until the interaction is done. So there is no early release by the master, according to the spec.
First the device code is transmitted. When a device is present on the bus that owns this code, it will listen to further HSK operations. Otherwise, if there is no matching device, no one will participate, and the server will experience a timeout waiting for the response. If there is a matching device, the master is supposed to keep BAV low until the interaction is over, which means that the command was transmitted and its results were returned. (Section 4)
When BAV is pulled low, the attached slaves may expect a nibble to be transmitted, hence there is a timeout of 20 ms for HSK to go low.
When the master lowers HSK, it indicates to any addressed slave that there is a nibble on the data lines. As soon as the slaves sense a falling HSK, they pull down HSK by themselves. When they have read, they typically release HSK to indicate that they are ready for the next nibble. Usually the master has already released HSK. If the master senses that HSK goes high, it concludes that all addressed slaves are ready for the next nibble.
Suppose that you want to read a sector. This will take some time; the result is expected to be delivered in the response phase of the BAV low time. Now when the server has completed the transfer of the command, the slave will pick up the last nibble of the command, and then not raise HSK but keep it low until the whole sector is read. If you look closely, there is no timeout for HSK low, only for HSK high. The spec says at some positions that this is the proper way for a slow slave to control the progress of the communication.
According to the spec, early BAV releasing is only done by a slave requesting service from the master. The slave pulls down BAV, which is sensed by the master; the master then pulls BAV low also, which cannot be sensed by the slave, but then the master also pulls down HSK for the first nibble, and then the slave releases BAV which is still down by the master.
[Edit: BAV handling]
Edited by mizapf, Fri Oct 20, 2017 6:05 PM.