SCB SPI Master Not Actuating SS2

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
DaBa_1448511
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted

Hi Bob,

I am using the CYC8KIT-049 (42xx) plugged into my own board, which has three SPI devices sharing the same SCB SPI Master. The one at SS0 is a LED matrix which speaks Motorola with 16 bit data. At SS1 and SS2 are two Microchip CAP1128 capsense button controllers, which also speak Motorola, but with 8-bit data. SCB is initialized as Unconfigured. My code works with the LED matrix and the CAP1128 at SS1, and I have identical code to operate that at SS2. I also have a UART that spits debug info over the USB serial, showing button activity. My problem is that the PSOC will not operate the SS2 pin, it just sits high. I used a logic analyzer to catch this culprit, and to ensure that it wasn't interference on my board, I unplugged the 049 board and still no waveform on SS2. My code is attached. I've commented out the calls to interact with the LED matrix and the working CAP1128, to simplify. Any advice would be much appreciated.

0 Likes
21 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Can't see any reason. did you check the pin for working correctly?

Bob

0 Likes

As mentioned, I did yank the 049 board and verified no signal. I guess it could be a dead pin, so I'll fire up a different board and see if that makes a difference. Thanks.

0 Likes

Hi Bob,

So I did swap to a different 049 board and got the same behavior. I went all over it again with the logic analyzer and saw good transmissions for ss0 and ss1, but confirmed no ss2 waveform. To take it to the next level I decided to eliminate ss2 and put a clock signal out on it, just to verify the pin is good. So I stripped out all the code for the device at SS2 and un-checked the box for ss2 in the Unconfigured SCB. But the SPIM was not agreeable with this, and did not operate normally anymore for the other two slaves. (Looked like it was trying to use very long data words). Is it possible there's a problem with the internal code for the SCB?

Thanks.

Dave

0 Likes

I would suggest you to

  • Try a different kit, one where you have debug capabilities on. Debugging will reveal any errors we haven't thought of yet.
  • Try to create a support case to get help by a cypress engineer.

Bob

0 Likes

Bob,

Thanks again for the help. I just happened to have a CY8CKIT-059 in a Mouser box waiting to be opened, so debugger added, and all went smoothly. I decided to try swapping the SS1 and SS2 pins and this seemed to show that there is a problem with the SCB block, as the result was that the opposite CAP1128 began to work, and the one that worked before did not. So I bundled two projects up, showing original and swapped scenarios, and created a support case.

Dave

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Bob,

I see this morning that my case (Tech Support MyCase 00394760 ) is already classified as CANCELLED, recommending I go back to online resources. Attached is the content I had uploaded. Below is the text from the case. I'm not sure what to do next. Thanks.

I am using the CYC8KIT-049 (42xx) plugged into my own board, which has three SPI devices sharing the same SCB SPI Master. The one at SS0 is a LED matrix which speaks Motorola with 16 bit data. At SS1 and SS2 are two Microchip CAP1128 capsense button controllers, which also speak Motorola, but with 8-bit data. SCB is initialized as Unconfigured. My code works with the LED matrix and the CAP1128 at SS1, and I have identical code to operate that at SS2. I also have a UART that spits debug info over the USB serial, showing button activity. My problem is that the PSOC will not operate the SS2 pin, it just sits high. I used a logic analyzer to catch this culprit, and to ensure that it wasn't interference on my board, I unplugged the 049 board and still no waveform on SS2. I have since, created the attached pair of projects that I believe show the smoking gun. What I did was reverse the two pins for SS1 and SS2, which demonstrates that the problem originates in the SCB block, rather than at pins or external hardware. 

On Bob Marlow's advice I began using a Cypress debugger with the 049 board (I bought an 059 board and broke off the debugger board). So the two projects in the attached workspace are not implemented as bootloadable. 

Thanks for the help.

-Dave
0 Likes

Hi Dave,

have you tried to update to the newest SCB component version and/or using the latest PSoC Creator release?

According to register datasheet, the slave address values are 0-3 in order for the slave select lines.

I checked the header files, your current slave select values for the SPI control register are:

SS0 0

SS1 3

SS2 1

SS3 2

So, maybe it's related to this. As far as I can see, in the newest component versions, the addresses are also in order.

Regards

0 Likes

Hi Bob,

Thanks for that. I updated to the current Creator 4.1 and did Component update, which took the SCB from 3.2 to 4.0. No joy though.

I'm not familiar with where you're looking and seeing the out of order SS values. I wasn't able to find anything like that. Sounds like something that's outside of my control though...? If there's a way for me to put them in order, I'll need some coaching.

Thanks again.

Dave

0 Likes

You might try a different approach. Instead of using an unconfigured SCB you may use one that is configured as SPI with 3 ss lines.

See if that works.

Bob

0 Likes

Hi Bob,

Problem with that is, the CAP1128's are 8-bit and the MAX7221's are 16-bit. I guess your thought makes me wonder if I can use 16-bit mode with the CAPs and they would just not see the most significant byte. One experiment to try... Before that, I think I'll build up a duplicate of my existing project, but this time, make the MAX SS2. I'm seeing some other peculiarities with the existing project, where it no longer responds to swapping the pins on the CAPs. Weird thing now is, the CAP1128_B (U5) ALWAYS works, despite swapping SS pins, and the CAP1128_A (U11), which was originally the one that worked (on SS1), now never works. So I guess a from-scratch build-up is called for.

Thanks again.

0 Likes

onedashtwoeightone_1448511 schrieb:

Hi Bob,

Thanks for that. I updated to the current Creator 4.1 and did Component update, which took the SCB from 3.2 to 4.0. No joy though.

I'm not familiar with where you're looking and seeing the out of order SS values. I wasn't able to find anything like that. Sounds like something that's outside of my control though...? If there's a way for me to put them in order, I'll need some coaching.

Thanks again.

Dave

If you're referring to my post, I'm Ralf 😃

Regarding the update, maybe it's needed to delete the generated SCB API files, because even with the update it might be that the values for SS lines might be preserved.

I found the non-order SS values in the SPIM_SPI_UART.H file:

/* SPI slave select constants */

#define SPIM_SPI_SLAVE_SELECT0    (SPIM_SCB__SS0_POSISTION)

#define SPIM_SPI_SLAVE_SELECT1    (SPIM_SCB__SS1_POSISTION)

#define SPIM_SPI_SLAVE_SELECT2    (SPIM_SCB__SS2_POSISTION)

#define SPIM_SPI_SLAVE_SELECT3    (SPIM_SCB__SS3_POSISTION)

Now, if you check the values for SPIM_SCB__SS0_POSISTION to SPIM_SCB__SS3_POSISTION, you'll see that the values are 0, 3, 1, 2. If I understand the register manual correctly, the values for SS0 to SS3 should be 0, 1, 2 and 3 in order.

SPIM_SCB__SSx_POSISTION are defined in cyfitter.h.

In your project, they're defined as follows:

#define SPIM_SCB__SS0_POSISTION 0u

#define SPIM_SCB__SS1_POSISTION 3u

#define SPIM_SCB__SS2_POSISTION 1u

#define SPIM_SCB__SS3_POSISTION 2u

I cleaned your project, updated the components, build again and then checked cyfitter.h. Now, the result is:

#define SPIM_SCB__SS0_POSISTION 0u

#define SPIM_SCB__SS1_POSISTION 1u

#define SPIM_SCB__SS2_POSISTION 2u

#define SPIM_SCB__SS3_POSISTION 3u

Regards

0 Likes
lock attach
Attachments are accessible only for community members.

Ralph,

Thanks again for the help on this. Seemed like a good suspect you had, but I've now updated and cyfitter.h reads POSISTION  in the right order. What changed is that now ss2 does have a waveform, but ss1 is missing its waveform. Checked it all again on the logic analyzer. Saw a beautiful set of waveforms for a transfer involving ss2, but not ss1. I'm uploading my latest, which, by the way is no longer a bootloadable. As mentioned before, I'm using an 059 kit debugger now.

Dave

0 Likes

Hi Dave,

okay, now let's check a few other things... I'm confused about the assignment of the /SS signals to the /SS pins. Your latest project now uses all four /SS lines, with the following pin assignment:

SCB signalSCB pin (dedicated to SCB function)
/SS0SCB1.ssel0
/SS1SCB1.ssel3
/SS2SCB1.ssel2
/SS3SCB1.ssel1

If I understand you correctly, you've connected three slaves on signals /SS0 to /SS2, which corresponds to pins ssel0, ssel2 and ssel3. Is this correct?

So, is there any waveform on /SS3 (ssel1)?

If needed, maybe I can setup a CY8CKIT-049 board and try to reproduce your issue.

EDIT: your current project is not on the latest component versions (e.g. SCB is on 3.2, latest is 4.0).

Regards

0 Likes

Hi Ralph,

Ah-- Sorry for the confusing change -- You're correct. The reason for the change: Last night, as an experiment, I enabled SS3 and temporarily swapped the pins between ss1 and ss3 to see if my missing waveform might be there. I didn't see any change, though I didn't take the extra step of putting it on the analyzer.

From your table below, it looks like my change caused a new re-ordering of the signals?

Dave

0 Likes

Hi Dave,

my problem is that I can't say for sure if this combination (SS1 = ssel3 and SS3 = ssel1) is how it is intended to work. From my understanding, the sselx pins are directly tied to the corresponding SSx signals. So, I wonder if it's intended that someone can choose to set SS1 to ssel3 and vice versa by the pin assignment dialog. But this assumption has to be checked against the reference manual.

Assuming that the definition of SPIM_SPI_SLAVE_SELECT0, 1, 2 and 3 always equals to the ssel0, 1, 2 and 3 pin in order, you should see the signals on the scope. However, please check also with the analyzer.

Regards

0 Likes

Hi Ralph,

I will delete the SS3 and see that it goes back to correct order. I guess I may need to build something up from scratch with three slaves to see if a very simple version has the problem.

Dave

0 Likes
lock attach
Attachments are accessible only for community members.

Ralph,

I spent a bunch more time trying to make sense of what's happening. I actually built up what was supposed to be a simplified analogy to the existing code, just putting out simple writes and reads on each slave channel. But for some reason, I can't get it to work (no activity on SPI pins AT ALL!!). So I went back to the most recent code I sent you. Stripped out the SS3 and verified that the SS's seem to be back in order. Then I spent some time on the logic analyzer. Attached is a shot of just a wide-open capture. I believe what we're looking at is a call to CheckCAP1128_B, starting with all three SS lines going low, which is probably when SPIM is stopped. Then there is a long burst of data, which I marked incorrectly, thinking it was an update to the display, but it's the initialization code, which is 96 bits long. It's followed by twelve clean 8-bit transfers. In all the captures I did, the only activity on SS1 were those seen when SPI is disabled and a few other sporadic and short drops to zero.

I'm stumped. Let me know if you have ideas I should try. Thanks again.

Dave

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Dave,

please see the attached project. Here, I can see activity on all slave select lines. This project simply configures SCB for 4, 8, 12 and 16 bit transmission and sends out data.

Then, compare to your code to figure out where the error is. Please report back if you found the issue.

One additional question: have you modified the SCB API constants and definitions in any way? Or have you used your own values and definitions for configuring the SCB? If you've modified the API directly, maybe this would cause the error.

I ask because if I remember correctly, you're using the configuration structure directly from the API. In my project, I used a copy of it with modification regarding SPIM_SPI_MODE, etc. Please see my SPI init function and compare the struct against yours.

Regards

0 Likes

Thanks Ralph,

I'll go through this. I have not modified the original initialization structure. I made a copy, declared in the SPIButtons.h header file, and created two substitute variables SPIM_SPI_RX_8BIT_DATA_BITS_NUM and SPIM_SPI_TX_8BIT_DATA_BITS_NUM for number of data bits. For initializing at 16 bits, I use the original structure created by the tool, and use my alternate for 8-bit initialization.

Will get back to you.

Dave

0 Likes

Ralph,

Thanks again for providing the code. I confirmed that all waveforms are fine running this. There must be some problem in the way mine is written. I'll use yours as a starting place to re-write my project.

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Ralf, I'm finally back with a simple project that demonstrates dysfunction in the SPI functionality of the SCB component. I have three SS lines and my code talks to a CAP1128 capacitive sensing device, which there happen to be two of, on SS1 and SS2. In the attached project, I can select the device on SS2 and I get proper communication, however it's not with the device on SS2, it's with the device on SS1. When I select SS1 the SS waveform does not happen, and no communication is possible. Just to prove that there is no hardware problem preventing the SS1 from pulling low, I have also tried physically reversing the hardware, so that the opposite CAP1128 device is connected to SS1 when SS2 is selected. It also communicates correctly. I'm also attaching photos of the waveforms in each scenario (on logic analyzer).

0 Likes