LPCX1125 yields different output on different computers

[omerta]

Dear community, I'm facing a weird issue on my LPCX1125 board. I'm working on a simple PWM based on 32 and 16-bit timers of the board. On my desktop PC (Win10), I'm able to debug successfully, and control/observe the corresponding digital pins based on UART (ring buffer) and an oscilloscope.

However, when I switch to my Win10 laptop with exactly same LPCXpresso ide build, the signal from the oscilloscope becomes weird, like something interfering it. I'm attaching the code and oscilloscope data (corresponding to my desktop pc -the desired one-; and from the laptop -the weird one-). Actually, I've also plugged the board on my debian-linux; monterey-mac os (with the LPCXpresso ide installed), I got the same weird signal.

I couldn't figure out the error yet. Any comments or has anyone experienced a similar problem?    

[omerta]

Dear frank_m, I actually tried your suggestion and updated the UART_PWM code (uart_rb.c). However, the problem remains the same. Then, I just tried the timer_PWM, which basically sets PWM using that 32 and 16-bit timers (timer_pwm.c). I think here is the problem. Once again, when I debug timer_pwm.c on my desktop PC, I'm able to set desired PWM and frequency and observe smoothly on the oscilloscope. However, when I switch to my laptop once again, it acts as the "weird signal". By the way, I observe a noise on my oscilloscope before setting the PWM to corresponding digital pins. This noise doesnt exists in my desktop PC. Any comments? Could it be related to the USB ports? 

[frank_m]

> This noise doesnt exists in my desktop PC. Any comments? Could it be related to the USB ports? 

Ground potential differences / shifts ?
And, desktop PC use to have metal casings that reduce EMI radiation.

> However, when I switch to my laptop once again, it acts as the "weird signal".

But to be clear, I see this as a mere symptom. The cause is in your firmware, I believe. Since I have neither the full code nor the hardware, I can only give pointers. (And since I am not a NXP employee, I can't spend hours on analysis).

But from browsing through your code, it seems the PWM settings are coming from the host, via serial interface. And here, individual USB host settings for the serial adapter like package size and mode do influence the UART timing. But still, I suspect the cause is in your firmware code.

I would not set the PWM cycle in a "hard" fashion in a loop, but store it and only apply in the PWM cycle interrupt. You would need to check the reference manual how the timer unit reacts upon changing settings mid-cycle.

And second, I would avoid using floating point both for calculations and for printf/scanf() calls, especially on a M0. You could do the calculation perfectly fine with integer.

And I would check what this "Chip_UART_IRQRBHandler()" is doing.

[omerta]

Thanks again frank_m. As you said, there may be still code related issues. But, what I dont get here is, how LPCOpen timer code works fine (no UART, just the timer) and gets noisy when I plug the board different computer exactly same built.

[frank_m]

> ... , I'm able to debug successfully, and control/observe the corresponding digital pins based on UART (ring buffer) and an oscilloscope.

Which suggests you are UART communication within your code.
However, communication issues with USB-to-serial converters and PCs are not uncommon. They might even depend on the USB connector you plug it in, as different internal USB bridges might be involved.

Regardless of issues on the PC side, I suspect you have both the timer and the serial interrupt of your MCU firmware running on the same priority level. This can surely create jitter, inconsistencies and blockages.
I would suggest to increase the timer interrupt priority.

And under no circumstance call lengthy functions from within interrupt context, or functions that rely on other interrupts.
The "printf()" function (however it might be called in your SDK/library) is a prime example that usually violates both recommendations.

[omerta]

Thank you frank_m. "Regardless of issues on the PC side, I suspect you have both the timer and the serial interrupt of your MCU firmware running on the same priority level. This can surely create jitter, inconsistencies and blockages." I will check that and update the status.

[frank_m]

Assuming you don't have the most exclusive debugging tools in the 5-digits price range ...

One method to check for interrupt interference would be to toggle different GPIO pins to high at each interrupt entry, and back to low at exit.
Then you can set the scope trigger to the condition of both signals being high (if possible).