LPC810 differences between REV 2X and REV 4C?

[lpcware]

Content originally posted in LPCWare by frankvnk on Mon Feb 01 15:05:46 MST 2016
I ran into problems problem when i flashed code on a rev 4C mcu that worked fine on a rev 2X mcu.

This is a little test project to receive NEC infrared transmitter codes (see annexed LPCXpresso project - LPCXpresso v7.9.2 Build493):
[list]
  [*]I started with the LPC810_CodeBase from https://github.com/microbuilder/LPC810_CodeBase
  [*]Next, i ported the PJRC IRremote library from https://www.pjrc.com/teensy/td_libs_IRremote.html
[/list]

Some modifications were made to the mrt part in the LPC810_CodeBase to allow a more flexible mrt initialization - has been tested separately and works fine.
This code works fine on a rev 2X mcu : a short keypress returns the key code, a long keypress returns the key code followed by the repeat code.
On a rev 4C mcu, 99% of the time, i get a repeat code instead of a keypress code (short or long press, it doesn't matter). It seems the initial keypress is immediately lost or not detected.

The LPC810 mcu versions i used :
rev 2X
LPC810
M021F
6323501
+D2502X

rev 4C
LPC810
M021F
1S10202
+D3434C

System clock =  30MHz
IR receiver connected to PIO0_1.
LED connected to PIO0_3 (switched on/off using an mrt channel).
As PIO0_1 is also connected to the ISP button, i tried using PIO0_2 but nothing changed.
A lower system clock does not change anything either.

Are there, besides the comparator fix, other significant changes between rev 2X and rev 4C that would force us to change the LPC810_CodeBase initialization code?

Original Attachment has been moved to: IR_decoder_modified_MRT_IRremote_REV4C.zip

[lpcware]

Content originally posted in LPCWare by frankvnk on Mon Feb 22 10:19:08 MST 2016
Problem solved. As the mcu (rev 2X) was soldered on the LPC800 Mini-kit, i didn't want to replace it with a rev 4C since this was the only working board i had. I verified my rev 4X proto board several times but couldn't find any errors. Using a little test program (switch outputs on/off) and a scope, i compared the signals on both boards and noticed there was quite some noise on the proto board. Then i measured the 3V3 supply and it turned out a bad 3V3 regulator was causing all the trouble. At first, i suspected the decoupling capacitors were bad but as soon as i replaced the regulator, everything worked flawlessly. Quite annoying because the noise on the 3V3 supply was not sufficient to reset the mcu, otherwise, i would have discovered this problem much sooner.
Anyway, thanks for the input.

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Tue Feb 16 15:47:46 MST 2016
Concerning initialization: I'm sometimes sloppy about 'reserved bits'. If I do a read-modify-write operation, do I have to care about the reserved bits? They read 'undefined' and should be written as 0s. That prohibits |= and &= operations, that are so handy. Maybe look after something like this. Clock enables, Power control, etc by using |= or &= ...
Just an idea...

Marc

[lpcware]

Content originally posted in LPCWare by frankvnk on Tue Feb 16 13:15:24 MST 2016
Thanks for the comments but there's definitely something strange going on. As i don't have debug tools, i'm using trial and error to find out what's going on.

I ran other code (which i used before) that works fine on the LPC800 Mini-Kit (Rev 2X) : http://www.elektor-labs.com/project/lpc810-as-ir-decoder.14053.html
On Rev 4C it behaves erratically, lots of bad readings.

Most probable cause is a timing issue.
Perhaps the mcu initialization needs additional or different parameters - i'm currently digging into the manual but any help is welcome.

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Tue Feb 09 09:12:07 MST 2016
We all hate that - tested modules don't work any more!

I had a short look at you project code. No offence, but I'm almost always appalled by code not written by me, because I grew up without any influence from so-called professional tools, or any 'standard' c-library .
It puzzles my, why every embedded programmer seems to build a software-timer like this: use some hardware to generate periodic interrupts and increment some variable from this interrupt.
Bullshit!  |(  What was wrong with the hardware timer in the first place? MRT does the job MUCH better (precision, low overhad, no jitter) than any software solution, really. The only problem is: most programmers are not able to use the hardware. In the case of MRT, you have to use an reload value of 1<<30 and multiply the current counter value by 4 to get a timing value that perfectly wraps around smoothly for easy timing caluculations/measurements. No ISR, no RAM overhead, no waste of cycles!

Once you've saved calculation power, stack usage and lateness, I bet your program runs correctly.
Because I guess, you wasted up the small RAM with printf and other unneccessary stuff. LPC810 is pretty small in RAM.

The boot loaders differ from revision to revision, so does the RAM left behind after the bootloader finished its job. I made a bad experience similar to yours when switching from LPC213x to LPC213x/01. Because of such a subtle difference.

Hope this help a little bit.

Marc

[lpcware]

Content originally posted in LPCWare by serge on Tue Feb 02 01:13:54 MST 2016
2X seems to be a preproduction code because in the datasheet only 1A, 2A and 4C are mentioned. Concerning version 4C only the ISP entry pin changed from PIO0_1 to PIO0_12 on certain packages. Read the datasheet

So i think that debug is your best friend here. Step through your code.I don't have a lpc810 at hand so i can't test your code right now.

HTH