Announcements
IMPORTANT: Cypress Developer Community is transitioning on October 20th. To learn more and be prepared for this change, check out our latest announcement.
cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 6

zgarrard
New Contributor II

I am using the CY8C6116BZI-F54 PSoC 6 in a design and I am utilizing the internal SegLCD peripheral driver to drive a 3.3 V COG LCD with 46 SEGs and 6 COMs. I am having an issue where the when I command certain segments to turn off, it disables all of the segments on the same common line. It seems like the Device Configurator is generating code that is allowing this problem to occur. For example, in cycfg_routing.h, here are the defined terms for the COMs:

#define LCD0_DRIVE0_COM0 15
#define LCD0_DRIVE0_COM1 16
#define LCD0_DRIVE0_COM2 17
#define LCD0_DRIVE0_COM3 18
#define LCD0_DRIVE0_COM4 19
#define LCD0_DRIVE0_COM5 14

And here are the defined terms for the SEGs that I am seeing the problem occur with:

#define LCD0_DRIVE0_SEG9 15

#define LCD0_DRIVE0_SEG15 16
#define LCD0_DRIVE0_SEG16 17
#define LCD0_DRIVE0_SEG17 18
#define LCD0_DRIVE0_SEG18 19

I noticed there doesn't seem to be any LCD0_DRIVE0_SEGXY terms that happen to match LCD0_DRIVE0_COM5's value of 14. This creates a problem when calling the Cy_SegLCD_ClrPixel() function to clear the segment on each common with the same defined value. Let me explain. Considering the defined terms above in cycfg_routing.h, if I call the following functions in my application after initializing the LCD peripheral with all of the segments ON:

Cy_SegLCD_ClrPixel(LCD0, CY_SEGLCD_PIXEL(LCD0_DRIVE0_SEG_9, 0UL));
Cy_SegLCD_ClrPixel(LCD0, CY_SEGLCD_PIXEL(LCD0_DRIVE0_SEG_15, 1UL));
Cy_SegLCD_ClrPixel(LCD0, CY_SEGLCD_PIXEL(LCD0_DRIVE0_SEG_16, 2UL));
Cy_SegLCD_ClrPixel(LCD0, CY_SEGLCD_PIXEL(LCD0_DRIVE0_SEG_17, 3UL));
Cy_SegLCD_ClrPixel(LCD0, CY_SEGLCD_PIXEL(LCD0_DRIVE0_SEG_18, 4UL));

It will disable all of the segments on COMs 0 - 4, even though I only intend to clear a single segment with each function call. Upon further inspection of the CY_SEGLCD_PIXEL() macro, it seems like all of the LCD0_DRIVE0_SEGXY terms should be unique and different from all of the LCD0_DRIVE0_COMXY terms. 

So my question is, why is the Device Configurator and SegLCD Configurator tools generating these defined terms with matching values between the COMs and some of the SEGs? Am I missing something, or is there a bug with the configuration tool(s)? I checked the HSIOM routing for the pins assigned to each of the aforementioned SEGs and COMs and they are all using different HSIOM routing, so I don't believe this would be a hardware issue where the SEG signals are clashing with the COM signals on those pins.

I have verified that all of my pin assignments and segment mapping in the configuration tools are correct and all physical connections to my LCD are correct as well. 

I have included the BSP with the generated source files for the project I am referring to to aid in the discussion. Please let me know if I should include any application code, or if I am missing something, or if there may be an issue in the configuration tool(s).

1 Solution
DheerajK_81
Moderator
Moderator

Hello @zgarrard ,

Okay, I now understand your problem. Thanks for the clarification.

Yes, that's right. There are several pins that share the same HSIOM connection and will cause a conflict if two COMs or SEGs are assigned to the same HSIOM connection. 

Please find the attached excel that contains the pins that share the same connection. Assign the pins in such a way that there's no conflict. I agree it would have been easier if the configurator would point out this. I have filed an internal ticket to look into this. 

Meanwhile, manual assignments should let you move forward. Let me know if you have any further queries. 

Regards,
Dheeraj

View solution in original post

0 Likes
4 Replies
DheerajK_81
Moderator
Moderator

Hello @zgarrard ,

Each of the pins have a specific SEG or COM numbering. For example, pin P8_1 corresponds to P8_1_LCD_SEG55. You can find this in the cycfg_routing.h file. So, if you assign SEG0 to P8_1, then the macro LCD0_DRIVE0_SEG0 will get this value of 55.

#define LCD0_DRIVE0_SEG0 55

>> I noticed there doesn't seem to be any LCD0_DRIVE0_SEGXY terms that happen to match LCD0_DRIVE0_COM5's value of 14

I didn't understand why they should match. These terms get their values based on pins that have been assigned to the Segments and Commons in the device configurator. 

Regarding the function Cy_SegLCD_ClrPixel, it is used to point to a particular pixel in your SEG/COM mapping. If you want to turn off a particular pixel just call the corresponding LCD0_DRIVE0_SEGXY and the COM number. 

Since the datasheet of the LCD is not attached I cannot really tell if your SEG-COM mapping or if the pixels you are trying to clear are right or wrong but I hope this clarifies your doubts.

Let me know if you have further questions. 

Regards,
Dheeraj

0 Likes
zgarrard
New Contributor II

@DheerajK_81 ,

Thank you for responding. You are correct that the specific SEG and COM numbering is generated in the cycfg_routing.h file, and as you said, I can see that For SEG0:

#define ioss_0_port_8_pin_1_HSIOM P8_1_LCD_SEG55

#define LCD0_DRIVE0_SEG0 55

This works for SEG0, because 55 is not being used by any COMs. However, in the example I provided my Device Configurator allowed me to assign SEG9 to P10_7, and COM0 to P2_3 without any HSIOM errors. This means I will have

#define ioss_0_port_2_pin_3_HSIOM P2_3_LCD_COM15

#define ioss_0_port_10_pin_7_HSIOM P10_7_LCD_SEG15

#define LCD0_DRIVE0_COM0 15

#define LCD0_DRIVE0_SEG9 15

This is a problem because they SEG9 and COM0 have the same HSIOM connections, now if I try to clear the single segment on SEG9, COM0 it will clear all of the segments that use COM0 with this function call:

Cy_SegLCD_ClrPixel(LCD0, CY_SEGLCD_PIXEL(LCD0_DRIVE0_SEG_9, 0UL));

It seems like Device Configurator should not allow this to happen. This same effect also occurred on

  • SEG15 to P11_0 with COM1 sharing connection 16
  • SEG16 to P11_1 with COM2 sharing connection 17
  • SEG17 to P11_2 with COM3 sharing connection 18
  • SEG18 to P11_3 with COM4 sharing connection 19

Because of the shared HSIOM connections between some SEGs and COMs, I was never able to turn off the segments mapped to these SEG/COM pairs without disabling all other segments which use the same COM line.

Hopefully this makes sense.

0 Likes
DheerajK_81
Moderator
Moderator

Hello @zgarrard ,

Okay, I now understand your problem. Thanks for the clarification.

Yes, that's right. There are several pins that share the same HSIOM connection and will cause a conflict if two COMs or SEGs are assigned to the same HSIOM connection. 

Please find the attached excel that contains the pins that share the same connection. Assign the pins in such a way that there's no conflict. I agree it would have been easier if the configurator would point out this. I have filed an internal ticket to look into this. 

Meanwhile, manual assignments should let you move forward. Let me know if you have any further queries. 

Regards,
Dheeraj

View solution in original post

0 Likes
zgarrard
New Contributor II

@DheerajK_81, Thank you for helping me to investigate this issue. I am glad that we were able to track down the pin assignment error mode and find a path to mitigate the problem in the future. 

One more bug I discovered in the generated code is the macros generated for single segments that aren't part of a character, but are given custom names in the SegLCD Configurator near the bottom of cycfg_seglcd.h. They are generated as:

#define LCD_My_Custom_Icon (CY_SEGLCD_PIXEL( 0UL, 0UL))

The above generated definition references the wrong segment. It should be instead generated as:

#define LCD_My_Custom_Icon (CY_SEGLCD_PIXEL( LCD_SEG_0, 0UL))

This seems like it should be a simple fix to make in the source code generating utility.

0 Likes
Top labels