Hi @nspsck ,

This sounds like it might be the same as this issue - thonny/thonny#2886

However, just in case, there are some recent esp32 memory allocation changes as described in https://github.com/orgs/micropython/discussions/12316 . This shouldn't cause more than a very short delay (much less than a second) between iterations, though. (Previously, the whole PSRAM could fill up before any garbage collection pass - meaning no garbage collection pauses would happen until it filled up and then one long garbage collection pause would happen. Now, running code like this will trigger frequent smaller and much shorter garbage collection pauses.)

Hi projectgus,

This sounds like it might be the same as this issue - thonny/thonny#2886

Thank you for your response. I can confirm (well I hope...) that this is actually the case. As both using screen and the repl in thonny with the following code causes no issue what so ever.

import machine

b = bytearray(1024 * 100)

machine.soft_reset()

However, just in case, there are some recent esp32 memory allocation changes as described in https://github.com/orgs/micropython/discussions/12316 . This shouldn't cause more than a very short delay (much less than a second) between iterations, though. (Previously, the whole PSRAM could fill up before any garbage collection pass - meaning no garbage collection pauses would happen until it filled up and then one long garbage collection pause would happen. Now, running code like this will trigger frequent smaller and much shorter garbage collection pauses.)

Would there still be a possibility, that this is a gc related problem, if something like

b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)
b = bytearray(1024 * 100)

runs perfectly? The code is "at one go".

I tested this using mpremote with the latest firmware and couldn't replicate the problem. It does look like Thonny is the culprit.

MicroPython v1.20.0-396-g1dedb65e6 on 2023-08-24; FeatherS3 with ESP32-S3
Type "help()" for more information.
>>> 
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== from micropython import mem_info
=== 
=== mem_info()
=== b = bytearray(150 * 1024)
=== mem_info()
=== 
stack: 672 out of 15360
GC: total: 64000, used: 1840, free: 62160, max new split: 8257536
 No. of 1-blocks: 23, 2-blocks: 3, max blk sz: 18, max free sz: 3836
stack: 672 out of 15360
GC: total: 217856, used: 154960, free: 62896, max new split: 8126464
 No. of 1-blocks: 13, 2-blocks: 3, max blk sz: 9600, max free sz: 3836
>>> 

I tested this using mpremote with the latest firmware and couldn't replicate the problem. It does look like Thonny is the culprit.

Ye, Thonny is most likely the cause for this problem. Time to bothering them!