Stumping TypeError-appreciate help...

[JDRBoston]

I’m having a consistent TypeError that makes no sense to me. I would greatly appreciate your help in trying to figure out what is wrong so that I can correct it.

I am using MicroPython v1.12 on an ESP32 WROOM32 module. I had been running a script without problems, but suddenly I got a consistent 'TypeError: can’t convert ‘float’ object to str implicitly’ error. But this error makes no sense to me because it is referring to a variable (stepcycleCounter, in my case) that I had defined as a local variable (stepcycleCounter = 0) within the function that is throwing the error, and confirmed that had been defined as an ‘int’ using type(). The line of code that is throwing the error later in the function is simply incrementing the variable by one (stepcycleCounter +=1). Interestingly, I added a line to help with troubleshooting just before the problematic one (e.g. print(‘\n** stepcycleCounter type: ‘, type(stepcycleCounter)) and it is not being executed by the script - the traceback is referring to the subsequent variable incrementing line... In case it matters, gc.mem_free() reveals 62496.

I’ve look elsewhere in the script and made sure that the variable is not being changed to a float. The line causing the error is not calling for the variable to be a string one.

I’d greatly appreciate any advice.

Thank you!

[scruss]

Please post the line that has the error. We can't guess what you've written.

Most likely you've done something like this:

Code: Select all

val = 10.0
print("val is " + val)

This results in the same TypeError: can't convert 'float' object to str implicitly error.

Note that either of these following examples is fine:

Code: Select all

val = 10.0
print("val is " + str(val))

val = 10.0
print("val is ", val)

[JDRBoston]

Thank you, very much, scruss. But that doesn't seem to be the problem. Here are the lines associated with the variable and where the error was thrown:

(function declared)
# Initialize local variables
stepcycleCounter = 0
# Added to confirm that the problematic variable is an int - the REPL output confirms this
print('\n**stepcycleCounter type: ', type(stepcycleCounter))
...
print('{:^12}'.format(stepcycleCounter))
...
# Increment the step cycle number
# Added to confirm that variable is int, but this isn't sent out to REPL even though the subsequent line is flagged as an error
print('\n** stepcycleCounter type: ', type(stepcycleCounter))

# the error was thrown with this next step
stepcycleCounter += 1

I've confirmed that the print('{}'.format()) does not convert the variable to a float. What is curious is:
the variable should be an int though the interpreter thinks that it is a float at the time of the error
that the interpreter somehow thinks that the "+= 1" operation irequires a str (I've confirmed that I didn't enter an l instead of a 1)

Could this be a memory problem?

[jimmo]

I am using MicroPython v1.12 on an ESP32 WROOM32 module.

Very unlikely that this is the cause, but that is several major releases ago.

I had been running a script without problems, but suddenly I got a consistent 'TypeError: can’t convert ‘float’ object to str implicitly’ error.

What changed between it working and not working?

The line causing the error is not calling for the variable to be a string one.

It would be really helpful if you could post the exact code (with line numbers) and the exact error message.

It does sound a bit suspicious that perhaps the board isn't executing the same code that you have on your PC. How are you transferring files to the device?

# the error was thrown with this next step
stepcycleCounter += 1

This line can't raise an issue is stepcycleCounter is float. e.g.

Code: Select all

>>> x = 1.5
>>> x += 1
>>> x
2.5

Could this be a memory problem?

Unlikely. Unless you're very deep in a call stack, any other type of memory issues are guarded by the heap allocator. And like you say, you have 62k available.

[JDRBoston]

I apologize for the poor wording of my question and not providing the full code of the function so that I could get your advice. But I was more perplexed by what I thought was an issue with the hardware or glitch in the interpreter than with the code itself. This is because by ‘sudden’ I meant that the script stopped working, although it had in the recent past and I made no changes in it. But I had been working on other scripts that were stored in the device. This is because ultimately the device will have a suite of scripts for the user to employ while using the instrument - some to calibrate it, to change the instrument parameters, etc.

I think that I have fixed the problem by flashing v1.18 onto a different device, reloaded all the scripts, and then finding that the script that wasn’t working yesterday now functions as expected. Curious! I’ve not run into this problem using the ESP32 and MicroPython in the past. But, unlike my previous work, I am making a device that has a number of scripts and modules that are loaded onto the ESP32. This seemed not to be a problem over the past months while I worked on the other scripts, but popped up when I revisited this one.

I’ll try flashing v1.18 and reloading the scripts onto the device that was throwing the error yesterday and test whether there might be a hardware problem that developed in it.

jimmo, thank you for your comments about memory difficulties that can be encountered by being deep into a call stack! I will read more about this so and the heap allocator that I can learn what you mean. I’m not sure whether it is relevant, but after launch of the now working again script and gc collection after each library loading, there are 33,824 bytes allocated in the heap RAM memory (gc.mem_alloc()) and 77,248 bytes free (gc.mem_free()).

Thank you, very much, for all your advice!

[scruss]

I’ll try flashing v1.18 ...

Better to use 1.19.1, as it is current and fixes some ESP32-specific problems.

[JDRBoston]

Thank you!