Master Control Port Interface R/W

i'm testing Master Control Port Interface Read and Write through SPI with GPIO triggering. I'm trying to write a simple value then read it back at boot time but this seems not to work.

I opened months ago a bug report about Master Control Port Interface (perhaps i can't find it anymore in my messages history) and as said it should have been fixed with Sigma Studio 3.15, the report was made for I2C since SPI wasn't still available with Sigma Studio 3.14.

I also tested it here on the bench and could not get it to work. I tried SPI and I2C and neither would work. Also, I noticed that when it was triggered it did perform a write but it would only do it once. After that it did not do it again until after I performed a reset.

Attachments

i tested your application and it works as expected. So that's the answer, they only work with GPIO Conditioning blocks which carry the yellow interface pins? I misunderstood that cause in wiki there's an example using a DC block straight to interface input pin of Interface Write:

Here's an explanation to the problem with the master control port write and the DC module

write 6 to DC block

download then burn EEPROM 25AA1024 with the program

This writes the data and program to the EEPROM, which implies that the DC value 6 is written to the memory location allocated for DC module in the EEPROM (say ’X’).

write 7 to DC block

When 7 is entered in the GUI of the DC block, this value is not written to the EEPROM memory location ‘X’. (X still has the value 6 stored in EEPROM)

push the Switch to trigger the write block

When the switch is pressed to trigger the interface write, the data 7 is now written to the EEPROM in the address location meant for interface write data (say ‘Y’) . (Location X still has the value 6 stored in it and is not modified by this write).

power off then on the device

On Self boot, the DC module is restored with the value stored in its EEPROM memory location ‘X’ (which is 6, this does not show in the GUI as it is an internal change, and in the GUI the value is 7). This causes the Read back to display a value 6 and not 7.

but at point 5, if EEPROM has been stored at 'Y' with 7 by Interface Write than why when the device turns on Interface Read would output 6 and not 7? It's ok that 'X' is restored with 6 since that is part of program memory data but Interface Read should output 7 cause it should be reading the address 'Y' at boot time.

Interface Read should change its output at next power on and only read the memory location used by Interface Write (and if Interface Write has been triggered).

What is happening here is that Interface Read changes its ouptut costantly during runtime, however i don't know if this is happening just in the GUI or it's really reading it from EEPROM (this last one would imply that both Interface Write doesn't work since it would be doing the write operation without triggering and Interface Read is reading at runtime instead of boot time).

When i was testing this through I2C and opened a bug report (thread is now lost, don't know why) i remember that it was happening the same thing. Interface Write was working cause i could directly read the EEPROM through USBi and the stored value was there, so the issue was with Interface Read.

The interface read module on boot actually reads back 7 from the EEPROM location Y on the first sample, but this is later overwritten by the DC block value of 6(which is restored from the EEPROM location X).

The above mentioned happens because the Interface read gets the ‘read value’ from a local copy (not from EEPROM during runtime) which is updated when an input is provided to the interface write module irrespective of whether it is triggered or not. This is the behavior you probably observed. However this local value is not written to the EEPROM until interface write is triggered.

In conclusion, the Interface read module reads from the EEPROM only at boot time and is subsequently updated by any module connected as an input to the interface write module. This here is the intended behavior.

The value that you see in the interface read and interface write is the same memory location in the DSP. So every sample period it the interface read will read from that memory location and the interface write will write to it. This is the interface register 0 in this case.

So what will happen is that upon boot up the interface register gets loaded with the value from the EERPOM. Then the Interface read will output that value to the place it is connected to in the SigmaStudio schematic. Then the interface write will update that value in the interface register with the value that it is being sent.

So for normal usage this number will be the same. For a volume control or an index selectable filter the interface read will stuff the value from the EERPOM, let/s say #15. Then the volume control will switch to volume level 15 and therefore output 15 to the interface write cell. So they will both be reading the same number. Should you change the volume control the interface write will update the value in the interface register and you will see that the interface read will now display that new number because that is what is in the interface memory location. This all works fine. It gets primed with the EERPOM value at startup and then will always hold the current value waiting for the trigger to update the EERPOM.

So in your original program you were not using cells designed for interface read and write. There was a disconnect.

What was happening is that upon startup, the EEPROM value for the interface register is loaded and the interface read will read it and send it to the readback cell for a split second. Then the DC Cell value gets loaded with the value that was used when the original program was written to EEPROM. So now the DC cell in the DSP (not in the SigmaStudio GUI) has the original value in it. So now the interface write picks that up and writes it to the interface register location. So now the interface read reads this old value instead of the value that was in the interface register EEPROM.

So there was a combination of issues that made it seem like it was not working. The DC cell was overwriting the interface register, and SigmaStudio GUI was not showing the actual value that is in the DC cell in the DSP. Then there is the fact that there is only one interface register not a read and a write register. I hope that helps.

I did write two example programs that show how this works. I have readbacks on both the interface read and the interface write and you can see that they always will have the same value. The two files are one for SPI and one for I2C.

thank you for the elaborate explanations, now it's clear how Master Control Port Interface works and how it should be used. I tested it with GPIO Conditioning blocks within my application and it works fine. However i'm experiencing a different problem now and i'll open a new discussion since it involves Voltage Controlled SPI Delay too.