PIC32MZ + WS2812 Not Working

[ronaldlijs]

I have tried different things this past weekend without luck

When the LED doesn't work correctly, It seems the output signal always gets "corrupted" at the beginning of one of the colour bytes (Green, Red or Blue).

I have also tried with all lights turned off (as in RGB 0,0,0) and just refreshing the lights every second. The result is that some lights intermittently turn on as the output signal gets corrupted on some output pins...

Cheers,
R

[Benj]

Hello,

You've not got any interrupts active that might be jumping in while you are inside the tight refresh timings have you?

I've had a think about it and think I can improve the component further but not sure if this will solve your problem. I suppose it's worth a go and my improvements should allow for different timings to be entered for different components.

[ronaldlijs]

Hi Ben,

Thanks for your lines.

No interrupts on the code attached where we can easily reproduce the issue. We have tried putting the Refresh() calls at the end, in between, etc... didn't make any difference. Brightness() is not working BTW.

I've noticed the more code I add to the program (even without interrupts), the less LEDs work correctly and some LED outputs get corrupted.

Check my post with screenshots: Postby ronaldlijs » Tue Oct 29, 2019 10:08 am
9 LEDs work fine, 10 running and outputs get corrupted.

And on our main program, with other things running, with only 3 LEDs we see the issue.

Thanks!
R

[ronaldlijs]

Hi Ben,

I'm not sure if this is a component timing issue... the output gets corrupted and I have checked the code and whilst I am not a programmer, you use nop() for the high/low timings, which is perfect so the HIGH/LOW times must go out of the pin correctly, The C code for the definitions
T1HNOPSDEF
T1LNOPSDEF
T0HNOPSDEF
T0LNOPSDEF
when it runs and the problem appears, the beginning of one of the GRB byte gets corrupted:

Bitmap01.png

(17.81 KiB) Downloaded 2023 times

Look the rest of the bits, their timing is fine!

So what I would assume and after checking a bit the C code that the issue is maybe that some loop before outputting all bits is taking longer than usual and keeping the ouptut high/low. However I cannot understand the C code myself, there are different parts where the //Clock Out Data in GRB Format code is running, so wouldn't know exactly

Code: Select all

//Comment:
//Clock Out Data in GRB Format
switch (FCL_SUBINDEX)
{
	case 1:
	{
		//Comment:
		//First

		// .SubIndex = 0
		FCL_SUBINDEX = 0;

		break;
	}
	case 2:
	{
		//Comment:
		//Third - Done

		// .SubIndex = 3
		FCL_SUBINDEX = 3;

		break;
	}
	default:
	{
		//Comment:
		//Second

		// .SubIndex = 2
		FCL_SUBINDEX = 2;

	}
}

Hope this helps,
R

[ronaldlijs]

Just another question / suggestion.

Given the PIC32MZ is powerful and has got plenty of RAM, would it be possible buffer all 3x GRB bytes and treat them as 1 entity and prepare them to be sent out at once? (as in 1 loop only) Would that not make a difference when the outputs are engaged? It would be only high / low and nop() in between... so timing would be better?

Also I think I found something here... one more thing!

Most of the LEDs are only 1x LED component... but we have 3x LEDs with 25x LEDs each. This is interesting... When the output gets corrupted on the LED component with 25x LEDs, the ONLY corrupted bits are the first ones on the chain. The rest of the LEDs show fine!

So for example GRB 255,0,0 for all 25x LEDs, the signal looks like this:

Bitmap2.png

(26.13 KiB) Downloaded 2023 times

And for example GRB 0,255,0 for all 25x LEDs, the signal looks like this:

Bitmap3.png

(25.39 KiB) Downloaded 2023 times

Note that ALL other bytes timings are perfect and NOT corrupted. So this is an issue with the loop at the beginnig and for the first 3 bytes (first LED in the chain) or somewhere there...

Regards,
R

[Benj]

Hello,

I've had another go at the component and hopefully cleaned up the code allowing for multiple components each with their own timings and better pin optimisation. It's now available via the update system so let me know how you get on. It's interesting about the glitch you are seeing. I'm not getting this with a 16-bit PIC so there could be something strange the PIC32 compiler or silicone is doing. Hopefully we can work out what exactly.

Could the glitch be something to do with the LED's surging current and maybe tempoarily browning out the chip? Maybe try some big caps across the LED power rails and across the chip power rails to see if this helps at all.

[ronaldlijs]

Hi Ben,

Many thanks for your efforts! OK I have tried the updated code and same issue, but I would say a bit "worst"...

Just to clarify we are using 3.3V to 5V level shifters, we are not probing at the LED, but directly at the MCU pin output, I don't think this is an issue with the LED...

The scope trace below is the output of LED_MARQUEE component with 2x chained LEDs directly from the MCU pin output (A14). It has got 2 LEDs, notice -again as previous attemps!- that only the first LED signal gets corrupted, the second LED works perfectly well and the signal is perfect!

This time the first 3 bits of each GRB byte for LED1 got corrupted! If you count, it's always the first bit HIGH/LOW that gets corrupted, all other bits are fine... And for LED2, ALL 24x GRB bits are fine!

Bitmap4.png

(27.98 KiB) Downloaded 2016 times

Bitmap5.png

(54.77 KiB) Downloaded 2016 times

Cheers,
R

[Benj]

Hello,

Thanks for letting me know. Can you try with this and see if any of these optimisations make any difference. You should be able to enter the code in a C icon before your main loop.

https://www.microchip.com/forums/m505800.aspx

[ronaldlijs]

Thanks Ben again,

It doesn't compile :- ( Some errors on all code options...

Code: Select all

D:\Projects\CASHAR~1\Products\ELECTR~1\U22BEL~2\FC8\CONTRO~4\CONTROL_PCB_LEDS.c: In function 'main':
D:\Projects\CASHAR~1\Products\ELECTR~1\U22BEL~2\FC8\CONTRO~4\CONTROL_PCB_LEDS.c:23941:16: error: 'CHECON' undeclared (first use in this function)
   } else {
                ^
D:\Projects\CASHAR~1\Products\ELECTR~1\U22BEL~2\FC8\CONTRO~4\CONTROL_PCB_LEDS.c:23941:16: note: each undeclared identifier is reported only once for each function it appears in
D:\Projects\CASHAR~1\Products\ELECTR~1\U22BEL~2\FC8\CONTRO~4\CONTROL_PCB_LEDS.c:23941:27: error: expected ')' before 'x'
   } else {
                          ^

[Benj]

Hello,

Out of interest what type of level shifter are you using? If it's bidirectional then we have had problems with these in the past. It's almost like a warm up time to transmit. This doesn't explain the delay for R, G and again for B so this is very curious.

Maybe it's some sort of RAM fetch lag? Though I think the component fetches the value before it starts transmitting. I'll check this and if not maybe we can try loading this value into a new local variable to see if this helps.

Edit, just checked and we do save to a local variable so we can easily shift through the data without corrupting the buffer.

Code.jpg (67.12 KiB) Viewed 10384 times

[Benj]

Reading this it may be something to do with the "core timer", I'll investigate but doesn't seem right to me.
https://www.microchip.com/forums/m787021.aspx

This seems more on the money.

Even if you make sure that optimizations don’t meddle with your delay code, various factors like how the L1 and pre-fetch cache are configured and how many wait states are used might affect the timing. Your best bet is to use a timer as someone else suggested.

https://www.quora.com/How-can-I-write-a ... lliseconds

There's a ns delay function here that's probably worth a go. I'll try this tomorrow for you.
https://www.microchip.com/forums/tm.asp ... e=1#382062

[ronaldlijs]

Thanks Ben,

We are using bidirectional level shifters (TI ones). I have tried this morning something, I have removed one of the level shifter chips and now we have only the MCU pin out and can still see the corruption in the stream.

Very interesting this MIPS feature about the "core timer". I do understand now that the PIC32 is a totally different beast to any of the previous Microchip MCUs. This is a very good and simple explanation (for other people reading this post): https://blog.flyingpic24.com/2009/04/02 ... ore-timer/

Indeed I have tried the following code on this PIC32:

Code: Select all

int main()
{
	while (1)
	{
		SET_PORT_PIN(A,3,(0));
		nop();
		SET_PORT_PIN(A,3,(1));
		nop();
	}
	mainendloop: goto mainendloop;
	return 0;
}

As expected the timings for the signal are not even close to 5ns or 10ns or similar... They end up being 145ns... So nop() can be tricky here...

HTH,
R

[Benj]

Right I've thrown this together with little time for testing but hopefully it will compile for you. It's using the core timer rather then relying on instruction counts.

For now I'll just release unoficially so you need to copy the attached file into your "C:\ProgramData\MatrixTSL\FlowcodeV8\Components" folder before starting Flowcode.

LED_WS2811.fcpx

(15.32 KiB) Downloaded 216 times

Let me know how you get on.

[ronaldlijs]

Hi Ben,

FAN-TAS-TIC, It works like a charm!!!

I am updating 18x LEDS on our test program without any problem at all! I will give it a try on our main program where I have timers, etc and get back to you with results, but feels as the solution is super solid as the signal output is clean and doesn't ever miss a beat.

MANY THANKS for this and keep up the bloody great work you all do with Flowcode.
Enjoy the weekend!!

[ronaldlijs]

Hi Ben,

I would say you have fixed this one... I've tried on our main program with at least 2 timers running with great success, we are going to run extra code this week so we will know better for sure.

However to say Brightness() control doesn't work, but we have managed to incorporate this in our code so it's not really needed for us atm.

Thanks again!
R

[Benj]

Hello,

Many thanks for testing for me, glad the timing issue is now resolved. I might create a new PIC32 core timer component as this should be easy to do and quite useful.

Regarding the brightness, I've been using the new byte based brightness and this is working ok for me. When you say it's not working can you give an example. Note for the brightness to work you have to set the brightness level and then assign the colours to the LEDs and refresh. We do not scale any of the colour values already loaded in.

e.g. this would work.

SetBrightness(0.1)
SetAllColours(255,0,0)
Refresh

This would not work

SetAllColours(255,0,0)
SetBrightness(0.1)
Refresh

I've maybe spotted somethign with the floating point brightness function so I've hopefully solved this and pushed the new component to the update system.

[chad]

Speaking as an ex lighting designer and someone who is also going to be using this, being able to adjust global brightness would be very nice to have.
Just fyi.

Thanks,
Chad

[Benj]

Hi Chad,

The SetBrightness does effect global brightness but you have to assign the colour values after setting the brightness.

I can't think of a better way around this without resorting to a secondary buffer which would be memory intensive or scaling values on the fly which would effect the strict timings required by the LEDs.

[ronaldlijs]

Chad,

In our setup, we use a routine that takes LED number, colour and brightness variables (as indexed values however) after which the piece of code calculates and sets the resulting colour / brightness for the given LED, this works great for us. We do have 2 routines, one for individual LEDs (14 individual LEDs), the other for 4x LED strips (25x LEDs) as we have both in our setup...

HTH,
R

[ronaldlijs]

Hi Ben,

I understand now and thanks for clarifying this!

e.g. this would work.

SetBrightness(0.1)
SetAllColours(255,0,0)
Refresh

This would not work

SetAllColours(255,0,0)
SetBrightness(0.1)
Refresh

Before moving to PIC32 and WS2811 we were on dsPIC33 and APA102 LEDs and always using the second way of doing this which was obiosuly wrong!

Cheers for this, much appreciated!
R

[ronaldlijs]

I might create a new PIC32 core timer component as this should be easy to do and quite useful.

This could very useful indeed Ben.

Thanks,
R

[Benj]

Hello,

This could very useful indeed Ben.

The new component has been made and it should be available now via the update system.

[ronaldlijs]

FAN-TAS-TIC!!! Thanks Ben!

Only thing to note is that the following code doesn't seem to change the brightness of the LEDs on the output. Brigthness stays always at 1. Strange...

LED_Brigthness.jpg (21.93 KiB) Viewed 10207 times

For now we are using a custom routine to change the brightness against the colour, easy to do.

Regards,
R

[Benj]

I've just had a look and it seems inverted.

0.0 = full brightness, 255 or 1.0 = Off.

I'll get this fixed ASAP.

[Benj]

Thanks for letting me know. The brightness issue should now be completely fixed in the latest component updates.