topic Re: Help! Failed to replace LPC2132 by LPC2136/01 in LPC Microcontrollers

Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:00 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Sat Aug 03 11:01:36 MST 2013
Hello, I use LPC213x since a long time. I build a board, recently for the LPC2134. I like the simplicity of these devices, compared to the LPC1700/LPC1100/LPC800 sometimes. I have a stock of LPC2132 and intend to use them for some motor drive/SMPS projects. For program development I want more RAM, hence decided to use an LPC2136/01 for that. I assembled 3 boards, 2xLPC2136/01 and 1xLPC2132 (old).
I thought, I had understood, that the /01 devices are drop-in replacements, if I don't use any new features of these. But that is exactly, what is not happening. While several programs work with LPC213x (old) they do not with LPC213x/01 ?

When limiting functionality of the programs to GPIO, DAC and Timer0 only, I still don't get the same behaviour. The behaviour of the old device is as expected. The new ones behave abnormally: simple button presses not recognized, Timer0-based timings totally off and things like that.

I found out, that I seem to have a problem with the SCS. In my program it is NOT the same (for the /01 devices), if I leave that untouched (its RESET value is supposed to be 0) or if I write 0 to it!! Let alone if I use read-modify-write. Okay, read-modify-write is - strictly speaking - wrong, as it may place 'undefined bits' into locations that should be zero. But still, why a difference between RESET contents and zero?

I found nothing in the User Manual or Errate Sheet.
Did any of you ever experience something similar and how did you fix it?
There must be something I've missed.

I know about fast IO, fractional baud rate generator. Is there anything else different?

I regret to have deleted the original User Manual of LPC213x of the time before /01 devices. But I guess, SCS was simply non-existent in these devices and not touching it should provide portability.

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:01 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Sat Aug 03 18:12:32 MST 2013
I returned to the problem and narrowed it down:

I seems like that: If GPIO is enabled for P0.25 and I change this pin's direction to output, then it won't work if switched to AOUT (function 2) later by PINSEL1 - at least if that happens within a few instructions. See program attached. And it fails on the /01 device only, never on the 'old' device.

Is there any difference between old devices and /01 devices concerning memory alignment, i.e. core differences ?
I'm executing my program from RAM, so FLASH differences cannot matter.

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:02 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Sun Aug 04 06:43:07 MST 2013
Sorry, it's all my fault.

I messed up the stack in my linker script for the RAM-execution image.
The old and the /01 do behave different, but that difference happens in programs with incorrect stack setup. We don't care about that, do we?

This problem brought the roof down on my head...

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:02 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Mon Aug 05 15:42:08 MST 2013
Sorry again: NO it wasn't my fault.
It's the NXP's bootloader programmers fault!

Sorry for my monologue - but it seems nobody cares. We'll see.

I went on with correct stack setup and strange errors kept occuring! On the /01 device only.
Now, what turned out:

On LPC213x (old):
When the bootloader finds out, P0.14 is NOT pulled low and valid user code present,
it starts the user code and does nothing else. That's what we expect, right? This is
consistent with the user manual paragraph 2.4.11: ISP commands use on-chip RAM
0x4000 0120 to 0x4000 01FF. Yea, and if we don't use ISP commands, this RAM is left
alone - fine.

On LPC213x/01:
The bootloader runs amuck in this RAM area, whether or not there's anything to do
other than launching valid user code.

Or the other way round: LPC213x/01 will always destroy your lower RAM area, even from a
watchdog timeout, because that's exactly how I launched my code from RAM.
This IS a difference. And it is not a backward compatible one!
Next thing, I'll check is whether this f**ked up boot loader is also in LPC800.

I'm very sad about that. Because I wrote a small RAM-loader to execute code im RAM only.
It's placed in FLASH and it uses - literally - not one bit of RAM. So I'm asking myself,
why professional NXP boot code developers do need RAM for launching user code in the first place.
I do run a protocol, put data into the RAM and launch without using RAM for my program ;-)

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:03 GMT

Content originally posted in LPCWare by Oliver Sedlacek on Fri Aug 23 07:38:31 MST 2013
I hope you get this sorted. I'm really struggling with my LPC2136 boards and getting pretty demoralised.

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:04 GMT

Content originally posted in LPCWare by TheFallGuy on Fri Aug 23 09:01:12 MST 2013
Marc,

The ROM bootloader does a lot more than boot your code. It has to calibrate peripherals (especially the IRC) as well as looking at the boot (ISP) bins and making decisions based on that.

As far as I know, NXP make no guarantees about preserving the RAM when running the ROM bootloader. You have relied on something that 'worked' in on version of the ROM and not in another.

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:04 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Fri Aug 23 11:47:02 MST 2013

Quote: TheFallGuy
Marc,

The ROM bootloader does a lot more than boot your code. It has to calibrate peripherals (especially the IRC) as well as looking at the boot (ISP) bins and making decisions based on that.

As far as I know, NXP make no guarantees about preserving the RAM when running the ROM bootloader. You have relied on something that 'worked' in on version of the ROM and not in another.

Yes and no.
Chapter 4.9 says: ...and internal SRAM values are preserved throughout Power-down mode...
What's the point in preserving values in Power-down if the bootloader overwrites these once power is up again?

What's missing in the manual (UM10120 Rev4) is a clear statement: The bootloader is executed on every reset / wakeup and it always uses the RAM area 0x4000 0000 to 0x4000 0270. Maybe additionally (I don't know) the higher 32 bytes of SRAM.

Looking at the ISP pins is one LDR instruction and one TST. Not that hard, really.
I don't know what the bootloader does. I wonder, if it is the bootloader, that fills in most of the 'RESET' values of the peripherals.

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:05 GMT

Content originally posted in LPCWare by TheFallGuy on Fri Aug 23 14:58:00 MST 2013
The boot loader will be run during a reset but not during a wake up. Perhaps you are doing something wrong....

The boot loader does a whole bunch of stuff, try decoding the rom...

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:05 GMT

Content originally posted in LPCWare by TheFallGuy on Fri Aug 23 14:58:03 MST 2013
The boot loader will be run during a reset but not during a wake up. Perhaps you are doing something wrong....

The boot loader does a whole bunch of stuff, try decoding the rom...

Re: Help! Failed to replace LPC2132 by LPC2136/01

lpcware — Wed, 15 Jun 2016 19:49:06 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Mon Aug 26 05:11:50 MST 2013
I see. Sorry!
I made an assumption on RAM that is indeed documented nowhere.
There is no information that can be transferred through RAM from one 'life' of a program to its next 'life'. I got that, now.

And yes, I will have a look at the bootloader's code.