Hello [email protected],
When using the 2 constant blocks and 1 mux (like in your example), I was able to reproduce your error. What happened in this case is Simulink coder saw that variable as if it was only 1B instead of 2B. I was able to get the desired output on SPI using a constant block, as shown in the image below (using an array of 2 uint8_t variables, 0xCE and 0x71).
This is the output I am getting:
I am transmitting 0xCE71 in 1 transfer, using the following options:
Note that the MOSI is still going up (at about 1.8V) for ~0.12us, but due to the sampling of data being done on the trailing edge of the clock, this does not impact the message. This issue will be sorted out with the SDK team - when they will have reached to a conclusion I will let you know.
Also note that this has been done with the PEBRIDGE set to 50MHz (but no notable difference versus the old configuration).
Kind regards,
Razvan.
Hello constantinrazvan.chivu, adriantudor and mariuslucianandrei
Using the Frame Size configuration = 8 with Continuous Transfer to send some "Read Command", I still get some response via SPI (As already stated previously for the SPI Device ID message).
However, when I try to send some "Write command", I directly get an error.
As example I am trying to send the WD_WINDOW command to configure the watchdog window duration to 12 ms (SPI output message 0xCE71).
Watching the SPI_Output on oscilloscope, it seems to be sending the message 0xCE00 (What causes a SPI error):
By checking the generated code, the DSPI_MASTER_TRANSFER function sends the SPI output when called.
Function Call:
Local Variable:
Values in memory:
I believe some problem is going on.
I imagine that the bytes of the command 0xCE71 shall be placed consecutive in the memory in order to send the data to the SPI transmit buffer.
What do you think?
Please let me know a solution as soon as possible.
Regards, Rafael
Hello [email protected],
When using the 2 constant blocks and 1 mux (like in your example), I was able to reproduce your error. What happened in this case is Simulink coder saw that variable as if it was only 1B instead of 2B. I was able to get the desired output on SPI using a constant block, as shown in the image below (using an array of 2 uint8_t variables, 0xCE and 0x71).
This is the output I am getting:
I am transmitting 0xCE71 in 1 transfer, using the following options:
Note that the MOSI is still going up (at about 1.8V) for ~0.12us, but due to the sampling of data being done on the trailing edge of the clock, this does not impact the message. This issue will be sorted out with the SDK team - when they will have reached to a conclusion I will let you know.
Also note that this has been done with the PEBRIDGE set to 50MHz (but no notable difference versus the old configuration).
Kind regards,
Razvan.
Hello constantinrazvan.chivu,
Indeed the configuration is 16 bits and the transmit is a mux with two sets of 8 bits.
But I had to use this approach because the SPI Transfer block just accept uint8 input datatype.
Also I tried to run the example with the configuration frame size 8 and continuous transfer
but still there is a unexpected behavior in the SPI output, as you can see below: The SPI message is 0x1400. There is a unexpected step (the last one).
Also you can check the strange clock behavior during the transmission on the below picture:
Kind Regards, Rafael
Hello [email protected],
I saw the rest of your messages after I posted my last reply - I saw that in my own example as well - that is indeed strange.
In my case it goes to around 2V4, so it does not reach ~3v2 as the valid data does. adriantudor suggested that it might be due to MOSI pin being undriven for a small period of time, while having a pullup. This can cause the pin to start going up, then the SPI starts driving it again. I will investigate this behavior, but in your case, having the clock phase set to the trailing edge (2nd edge) and the clock polarity to active high, that part of data will not be sampled (so it is read as '0' even though the logic analyzer clearly catches it).
Kind regards,
Razvan.
Just to explain a bit better the impact of this transmit strange behavior:
Taking as example the read command: SPI Device ID (0x1400),to the MC33FS6522LAE device
The expected input response is: 0x08F2 (Response get by the C code example from S32 Design Studio).
It means: No error, just the IO_G active.
Using the Frame Size configuration = 16, I got the response: 0x8FF2,
Which means SPI_G error and the fields VPRE_G, VCORE_G and VOTHERS_G active.
After using the Frame Size configuration = 8 with continuous transfer, I got the response: 0x0FF2.
The SPI_G error is not triggering anymore.
However the fields VPRE_G, VCORE_G and VOTHERS_G are still active.
That is it.
Kind Regards, Rafael
Hello, I would like to share some screenshots that show out what is the behavior of Chip select, Clock and SPI Output for the model sent attached on previous message
From my understanding the output of CS has a wrong activation after sending the message.
Probably it is causing error when reading the message.
Can anyone support me with it?
Kind Regards, Rafael
Hi Rafael Barbosa,
In order to read registers/messages from SBC you must requested data thru MOSI, wait more than 500 ns, then read MISO.
Best regards,
Adrian
Hello adriantudor,
Thank you for the response.
I don't know if you had a chance to look into the .zip file that I sent on the first post, but I am using the MBD implementation to send the reading command:
From this implementation with the used SPI configuration, I expected to see just the firsts 16 bits. The seconds set of 16 bits are not expected.
Regards, Rafael
Hello [email protected],
So the easiest way (minimum of change to your model) would be to change the SPI settings from the SPI Config block. Set
frame size = 8
and enable
Continuous transfer
to get the following signal:
Let me explain why these settings: on one hand, you'll have transfer size set to 2 (due to usage of MUX block); on the other hand, you want to send 16bits. Given this context, you can only set the frame size to 8. After you have these settings, you only need to enable continuous transfer so that you don't have the CS go HIGH in the middle of the 2 bytes.
There are other ways for achieving the same end result, but being necessary to change more blocks in your model, I don't see it become relevant.
The easiest way in managing any kind of SPI transfer is by using 8bit frame size with cointinuous transfer enabled and making sure you give the SPI T'ransfer block an input of appropriate size (the transfer size you need).
Please let me know if you have other questions regarding this subject.
Kind regards,
Razvan.
Hello Razvan,
Thank for the response.
The target is to read a simple SPI message of 16 bits size using the MBD.
Below you can see a correct message output using the example from S32 Design Studio (direct C code).
Kind Regards, Rafael Barbosa
