cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 6 MCU

New Contributor

Just started playing with a PSoC 6 BLE Pioneer Kit today, and I'm very much still in the "doing stupid things" stage. Because I'm hoping to be using the Smart I/O peripheral, I put together a (supposedly) trivial example to understand it.

1) The user switch on the pioneer kit is directly connected to the red user LED. This gives me a way to make sure I'm not doing anything too silly (sitting in reset).

2) I have driven the orange user LED with a PWM peripheral; this allowed me to confirm that the clocks are correct and that the processor is running my init functions as expected. This has since been removed from the example, for simplicity.

3) I have driven the orange LED by the switch input running through a pair of double synchronizers (using a status register), and this worked as expected. This allowed me to confirm that taking the switch input signal through the UDB block with synchronizers is a reasonable approach.

4) I would like to have the Smart I/O block, in asynchronous mode, invert the switch input, and have the output of this drive the orange LED. (Yes, I know there's no reason to use Smart I/O for this -- this is just my initial attempt to bring up the Smart I/O peripheral). Unfortunately, neither the switch nor the LED are on Smart-I/O-capable GPIOs. Instead, it looks like the Smart I/O peripheral data ports can be routed to and from status registers -- hence the use of synchronizers above.

So, the intended configuration is that the Port 9 Smart I/O block, running in asynchronous mode, has data[7] as an input from the switch (after routing through a synchronizer to make it routable); and data[6] is the output of the LUT that computes the inverted value, which drives (through a synchronzer) the LED. Yes, I'm aware this is silly -- but I'd still like to understand why it doesn't work.

The observed behavior is that the LED is driven as though by the first entry (all zeros) of the LUT), regardless of the state of the switch. That is, if the first entry in the LUT is 0, the (active-low) LED is on, no matter what; if the first entry is 1, the (active-low) LED is off. This, combined with the previous experiments, leads to me to believe that (a) the Smart I/O is being configured in its Init() function correctly and (b) either the Smart I/O routing or the input routing is screwy.

Any suggestions on where to look next?

pastedImage_1.png

pastedImage_2.png

0 Likes
Reply
1 Solution
Moderator
Moderator

Hello AdBe_4653416

You cannot connect the sync block to the smartIO component. If you check the data7 block, there are fixed components that can be routed such as PWM output, SCB blocks etc.

GPIO input can be taken, or driven only to smartIO capable ports (port 8 or port 9).

Best regards,
Hari

View solution in original post

0 Likes
Reply
5 Replies
Moderator
Moderator

Hello AdBe_4653416

You cannot connect the sync block to the smartIO component. If you check the data7 block, there are fixed components that can be routed such as PWM output, SCB blocks etc.

GPIO input can be taken, or driven only to smartIO capable ports (port 8 or port 9).

Best regards,
Hari

View solution in original post

0 Likes
Reply
New Contributor

"You cannot connect the sync block to the smartIO component."

Are you sure about this?

(1) I'd expect it to result in a routing violation when built, which it does not, although many other attempts to route in to smartIO do.

(2) The Smart I/O datasheet (002-17520 C) specifies that the data lines allow "connections to chip resources such as dedicated peripheral terminals or routed UDB signals," and the sync block generates UDB signals.

0 Likes
Reply
Moderator
Moderator

Hi,


Although the UDB blocks are involved, the signal cannot be routed to the pins outside the smartIO GPIOs.

I am checking internally why we have not placed a constraint in the top design regarding this. I will update as soon as I obtain the reason.

Best regards,
Hari

0 Likes
Reply
Employee

Hi Hari,

I think you are wrong, the SmartIOs are places in between HSIOM and the physical GPIO Pin and can do modification to the signal.

I am not sure why there is a pin function setting in the component, but I can't see any code generated based on it right now (cyfitter.h and SmartIO.h). Which to my knowledge makes sense as the SmartIO Registers also have no value associated to it.

Probably it is only for documentation?

I just tested it with a software PWM using a Control Register and inverting the signal with smartIO on button press by reconfiguring the SmartIO LUT.

AdBe_4653416

I did some further testing with your setup and could reproduce the issue. The button routed through a sync block it not properly detected by the SmartIO Block.

pastedImage_2.png

For debugging I then added a third LED to directly see the Button Input in the SmartIO (just used a LUT with 0x01 setting) and with this the inversion of the LED worked. I am not sure where this is coming from, I have to debug it further.

pastedImage_1.png

By moving the Button Input to SmartIO input data2 it stopped working again.

pastedImage_0.png

So there is some correlation between an UDB input and the corresponding output being populated or not.

Achim

0 Likes
Reply
Moderator
Moderator

Hi Achim,

My understanding was similar and the conclusion I reached was since I was not able to route the signal to other pins. If you check, you do not have to call the SmartIO_Start API for the signal to be directly passed through to the pin corresponding to the data pin. That is, if we route the signal to data 0, Pin 0 will get the signal directly, which I believe we are seeing now.

My project has the following schematic:

pastedImage_0.png

I see Pin_2  and Pin_3 gets the signal, but not Pin_1 and Orange.

Thanks,
Hari

0 Likes
Reply
Top labels