rp2040 knockoff memory alloc fail

[krismc]

Got an rp2040 clone from aliexpress. Looks identical, in particular the amount of ram is the same for both boards.
Allocated Memory: 5056 bytes
Free Memory: 187008 bytes
Total Memory: 192064 bytes
But the knockoff is giving memory allocation errors for a program that the genuine pico runs OK. Left scratching my head as to where else the bean counters have shaved a few cents & bought me undone?

[GitHubsSilverBullet]

I'd find it rather unlikely — quite unlikely to be precise — that they've cloned the RP2040 chip.
Given the fact that the RAM is inside the chip, I'd search for the problem somewhere else…
(Firmware?)

[krismc]

Ah OK, didn't realise the pico does not use external psram like the esp32s. Same firmware on both boards & curiously the 'MemoryError: memory allocation failed, allocating 157476 bytes' remains if I shrink the .py I'm trying to run down to a ~4 times smaller .mpy

My instinct is the genuine pico I've just ordered is gonna arrive here before I get to the bottom of this.

[GitHubsSilverBullet]

157476 bytes. That's quite a number.

>>> 
MPY: soft reboot
MicroPython v1.26.0 on 2025-08-09; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> ba=bytearray(240000)
>>> from micropython import mem_info;mem_info()
stack: 532 out of 7936
GC: total: 245888, used: 244880, free: 1008
 No. of 1-blocks: 56, 2-blocks: 12, max blk sz: 15000, max free sz: 34
>>> 

Whenever I need a significant chunk of memory, I try to allocate that as soon as possible after start.
Never failed me so far.
On the other hand, if one tries to allocate that chunk after the system has worked for a while, the total memory might still be there. But it is fragmented, thus denying the allocation.

[krismc]

I do the 19k byte array memory reservation in the first few lines, after that all is sweet on the genuine rp2040 board. But on the knockoff, just a few lines after the reservation, the next variable I declare gives the mem alloc error. Weird, especially considering it still does it when I run the program as a .mpy instead of a .py which uses about a quarter as much ram.

[GitHubsSilverBullet]

'MemoryError: memory allocation failed, allocating 157476 bytes'

So the question is: what piece is trying to allocated almost three quarters of the memory?
And, even more important, what happens before?

[robert-hh]

So you try allocating 19k, and the error talks about 157476 bytes, that's about 154k. That is weird and indicates a different problem.
154k is about 19k * 8.

[krismc]

Happens when I try to read battery voltage with the adc. But knockoff board has the same 200k/100k divider for battery voltage on gpio4 as the genuine & the harmless little adc routine runs OK by itself on both boards so it's not that it's producing crazy high count values. But definitely something in the adc def because the rest of the program runs OK on the knockoff if I skip the adc read.

def _adc(tag):  
  modes=[]; Pin(tag, Pin.IN)
  for i in range(9):
    vals=[]
    for j in range(9): vals.append(ADC(tag).read_u16())                                                                                               # 200k/100k batt v divider on pin 29, https://github.com/orgs/micropython/discussions/13598
    mode=max(vals, key=vals.count); modes.append(mode)
  mode=max(modes, key=modes.count); return mode*V3v3/65535                                                                                            # v in volts

[robert-hh]

How exactly looks the code there?

[GitHubsSilverBullet]

There's nothing in there which could cause that problem. Except for the multitude of list creations and deletions.
It basically resembles:

def _adc(tag):
    adc = ADC(tag)
    maxval = 0
    for _ in range(81):
        maxval = max(maxval, adc.read_u16())
    return maxval * 3.3 / 65535   # v in volts

but without any list allocations.

[robert-hh]

And can you tell us all that's written on the rp2040 chip?

[robert-hh]

Why does the code re-create the ADC object each time? I would expect it to be created once,

[robert-hh]

That is still strange. I looked into the implementation details for the above code:

• ADC() allocates a fixed amount, which is the size of the ADC object.
• list.append() allocates, but only a small size for each iteration-
• max() and the implicitly called list.count() do not allocate.

I see no reason why this code should allocate that much memory. @krismc can you refine it to the line that causes the crash. Maybe you have to move each statement to a single line.

[krismc]

Limited myself to 1 stmt/line & 1 ADC instance Rob

353 def _adc(tag):  
353 modes=[]
354 Pin(tag, Pin.IN)
355 x=ADC(tag)
356 for i in range(1):
357 vals=[]
358 for j in range(1): vals.append(x.read_u16()) 
359 mode=max(vals, key=vals.count)
360 modes.append(mode)
361 mode=max(modes, key=modes.count)
362 return mode*V3v3/65535

& ran it on the rp2040 knockoff board. Got 491 in m 396 in _getmetrics 347 in _getbatt 362 in _adc MemoryError: memory allocation failed, allocating 120186 bytes (log full, not saved). Not sure what you mean by 'all that's written on the rp2040 chip'? Do you mean the files in flash?

[robert-hh]

& ran it on the rp2040 knockoff board. Got 491 in m 396 in _getmetrics 347 in _getbatt 362 in _adc MemoryError: memory allocation failed, allocating 120186 bytes (log full, not saved).

I do not understand theses sentences. Does that tell that the error does not happen in the _adc() function? How is V3v3 defined? Is it by chance a string? Then mode*V3v3 would attempt to create a large string.

[krismc]

Got some genuine rp2040s today, they have the same mem alloc problem as the knockoff. So something different about the these latter days boards than the 2-3 year old picos I've been running this code on!

[robert-hh]

Not sure what you mean by 'all that's written on the rp2040 chip'? Do you mean the files in flash?

The it could be interesting to tell, whether there are different MCU versions at the boards. These versions are fine-printed on the CPU chip body.

[GitHubsSilverBullet]

Got some genuine rp2040s today, they have the same mem alloc problem as the knockoff.

That's been covered a while ago.

So something different about the these latter days boards than the 2-3 year old picos I've been running this code on!

We still don't have any idea what version of firmware is running on all those boards.

allocating 120186 bytes
Something somewhere does that. Most likely not your adc routine. Did you try the shorted version instead?

[krismc]

You're an inspiration Rob! The V3v3 value on the latter boards was stored as a string instead of a float, json is gonna be the death of me one of these days. When I run the _adc function in isolation it returns a more sensible error about not being able to convert a string to an int instead of the red herring mem alloc error I get in the full program. Tnx for the suggestion, I'd still be running around in circles here otherwise.

[robert-hh]

An important step to get along was putting each statement on a single line. Then it got clear that the statement mode*V3v3/65535 was the culprit. And in that only the part mode*V3v3 would be able to allocate large amounts of memory, with mode being in the range of 32000.

Having multiple statements at a line may lead to shorter source files and slightly faster compile times, but the readability is really bad and error tracking hard. So it should be avoided.

[krismc]

Fair point. My problem is scrolling. I already do way too much of it. If I limit myself to 1 stmt/line I'll be doing 2 to 3 times as much. I've tried alternatives like hiving the 'mature' functions off into a separate import but that has issues of its own & no matter how 'mature' I think a function is as soon as I move it to a separate import it needs to be edited which means opening another file. What I really need is a portrait oriented monitor that is about 1.5m long!

[robert-hh]

What I really need is a portrait oriented monitor that is about 1.5m long!

But then you get dizzy from moving your head up and down all the time.

About the _adc() function. Since you read the supply voltage, the values returned form adc.read_uv16() should only show a statistical noise without large outliers. Then, a simple average would do the job as well with only a few small allocations: one for the ADC object and one or two for the float values.

[krismc]

You're probably right. The _adc was originally developed for esp32s where large outliers seem to popup from nowhere & I just moded it for the pico, probably overkill. There's a lot to like about the pico, wish esp32 RTCs kept time as well as the pico.