Posts made by veryalien

Have a look here: esptool write_flash: error: argument : Address "{upload.erase_cmd}" must be a number

This problem seems to be caused by the esp32 2.0.5 update.

I don't think M5Stack are to blame, this was not a mandatory setting before.

After this update was installed I had the same problem with some of my M5Stack boards, but not all of them. A menu setting for erasing flash before upload or not must now be set. It seems that this menu setting must be sent to esptool, if this is not provided then esptool fails with the Address "{upload.erase_cmd}" must be a number error
There is a simple fix, if you can find your hidden arduino boards.txt file.
The path to the file will be different on Windows, Linux and OSX.
You need to add the following to boards.txt for ALL types of M5Stack/M5Stamp boards and then uploads should work again:

<board_name>.menu.EraseFlash.none=Disabled
<board_name>.menu.EraseFlash.none.upload.erase_cmd=
<board_name>.menu.EraseFlash.all=Enabled
<board_name>.menu.EraseFlash.all.upload.erase_cmd=-e

Replace <board_name> with the correct name for each type of board in the complete list. You can see what the name should be in the section for each M5Stack board.

After editing and saving boards.txt in the correct place, you need to restart the arduino IDE. You will then see in the Tools menu Erase All Flash Before Sketch Upload: Disabled/Enabled. This is the missing required setting for esptool.

Make a copy of your boards.txt before you make any edits so you can recover from any incorrect changes.

Good Luck!

I fixed the problem with the cam2core on the core2. So the UnitCam will work with Arduino IDE code and the core2.

It is a very simple fix:
Replace the first line #include <M5Stack.h>
with #include <M5Core2.h>

Initialising the core code on a Core2 is not the best idea!
Now it works on my Core2 showing the video stream from a UnitCam connected to PortB (pins 26, 36).

Confirmed, the UnitCam does NOT work at all on the Core2 in UIFlow or Arduino.
The Arduino UART to Core does NOT work on the Core2 - it does not boot.
I managed to fix this problem!
I will just use my UnitCam on my Cores and wait until it gets fixed for the UIFlow Core2 - if ever.

I can confirm that the UnitCam does NOT work with UIFlow 1.9.8 on a Core2.
It does not seem to be supported.
A UnitCam stream works without a problem connected to PortB with UIFlow 1.9.8 on an original Core. I have not properly tested the cloud functionality - it didn't seem to work for me. QR code for the url was never displayed.
There must be some technical reason why the UnitCam stream doesn't work on a Core2. Different UART behaviour?
However there is NO warning on the UnitCam store and doc pages that it currently does not work in UIFlow 1.9.8 on a Core2. If you only have a Core2 I don't think it will work. Luckily I have both Core2 and origjnal Cores so I could get it working.
Has anyone successfully tried a UnitCam on a Core2 with Arduino instead of UIFlow?

I cannot run the latest M5Burner with Ubuntu 18.04. It complains that glibc 2.28 is not found.
Unfortunately glibc 2.27 is the most up-to-date version on my system. I cannot upgrade to a newer Ubuntu.
Earlier versions of the M5Burner worked OK. I upgraded to be able to burn firmware on the latest M5 boards like M5Stamp.

This exact problem has been fixed before, see below. Can you please rebuild the M5Burner depending on earlier versions of the system libraries?

Re: Cant run M5Burner in Linux

I've just tried using my atom tailbats with a new OLED Unit and spent a long time wondering why the tailbat grove port didn't seem to work with the OLED.
The USB power and grove connector have really bad electrical connections on my newer matrix atoms (with diffused plastic over the LEDs). This stops the pass-through grove port from working properly unless I press the atom down onto the tailbat quite hard and hold it. The USB connector for the atom power usually works fine, but the atom grove pins don't connect cleanly to the tailbat. If I press too hard then the USB power connection fails and resets the atom (obviously). This is a really bad mechanical design which doesn't use a proper grove socket, it is done with a similar 4-pin connector socket with the correct pin pitch, but it is not grove.

I have just tried a couple of older Atom Matrix cores (with clear plastic over the LEDs) and the grove connector pins on the older Matrix Atoms are very slightly longer and make a better connection. With those, the OLED shows my test animation every time. It also works with an atom lite.

This is not good as I don't know how I can make all the USB power pins and grove pin connections reliable without touching or holding anything. Both USB power and all the grove pins need to work and both of the different connectors need to be in exactly the correct position at the same time. You can't really adjust anything on the tailbat connectors, they are fixed in place. It's difficult to see how the connections could be done with 'proper' grove and USB extension cables to the battery instead of the direct dual connectors. Putting some sort of kludge board between the atom and the tailbat is also a bit of a ridiculous solution, the tailbat and pass-through grove connector should really work on any atom, every time. I could just use the built-in grove port and a USB powerbank (if I can make it stay powered-on all the time).

Anybody else have anything similar? There are some other posts here that tailbats were not working properly, I wonder if some of those problems were actually the same bad mechanical connection issue?

@felmue It was "unconnectable" for about 24 hours, which was extremely annoying. The thing was that the devices could connect to the server and showed green connections. But the UIFlow server couldn't connect back to the devices.
I didn't change anything at my end and now everything is working as before.
I was trying to test the OLED Unit because of a brightness problem and that new unit is not yet supported in the desktop (offline) UIFlow IDE, so I had to be online and connected to try things out.

When I use the OLED unit with UIFlow 1.7.8 on a m5stack atom, the display is quite dim. It looks more like black and grey, not black and white.

It doesn't have good contrast, it looks like it is not getting enough power, but maybe it's actually the display initialisation that is the problem.

When I use arduino and the same m5stack atom with the adafruit sh110x arduino library, the same OLED unit is vey bright and crisp, definitely black and white, with very good contrast.

I suspect the OLED contrast is not getting set correctly during the init.

There are no blocks in UIFlow to adjust the contrast so it cannot be changed.
In arduino I can change the contrast (setContrast) and I can make the display darker or brighter.

Is there something wrong or incomplete with the 1.3" OLED unit display initialisation in UIFlow?

It seems to be working again, my browser now gets a connection to my device. So it was a server-side problem, nothing to do with our m5stack devices, firmware or API keys.

I have the problem that I cannot currently connect to any of my devices with UIFlow from flow.m5stack.com
For example core2 and atom devices can connect to the cloud server as usual and show a green connection.
When I try to connect to a device from my browser, it just says that the connection failed, maybe your device is offline..... All of the API keys I am using are correct. I've recently updated most of my devices to version 1.7.8. and everything was working until today.

Everything works perfectly fine locally via USB.

@fonix232 I've now 'successfully' used a 128GB SD Card (SanDisk Ultra) formatted as FAT32 with the M5Paper.
I haven't tried writing files using the M5Paper, but I can read text files and jpg files using the factorytest without any problems.

@mwenghi I've worked out that set_checked does actually work. It changes the internal state of the checkbox from unchecked to checked, but it's not changing the visible state of the checkbox on the screen, so it doesn't appear to do anything!

If you add a set_checked_color call (in blockly it's the block set selectedColor) after your set_checked it will then show the relevant checkbox as checked in your desired color.

I would like to be able to buy a Core or Core2 without any base or battery attached.

After buying some m5go, node and faces bottoms I already have more bases than cores. If I buy more cores I will get more bases and batteries that I do not need and they just lie around not being used.

If you sell only the top part of Core or Core2 with the main board and display, we could check the pin compatibility and match them with already purchased battery bases.

@kevindtimm I'm glad you've got the SD card working.
You actually have all the low-level.M5Paper hardware information closer than you think. On the back of all cores there's a colourful sticker. It's not just a pretty diagram. It's got just about all of the hardware details that you might need. If you look carefully at the list of pins for the SD card you'll find CS on pin 4!

@lukasmaximus I'd like to know why all the M5Stack cores (and the Atom TF card) show 16GB as the maximum SD card size. The ATOM GPS Development Kit doesn't show any details for the TF/SD max card size at all, probably 16GB!
I did some research on the net, and I think cards formatted to FAT32 at least up to 32GB 'should' be ok.
I vaguely remember a m5stack post about one of the camera boards where there was a table of compatible and incompatible sd cards. I didn't really understand why some of them worked or didn't work, perhaps transfer speed for video data?
Actually it was here on the here and that's not an ESP32.
Perhaps 16GB is listed as the 'maximum' as this will definately work? Anything above that might have some issues, so 16GB should be the safe option.
Depending on the hardware in the cores, it might be an issue with the SPI SD card slot controller, I'm not sure.
I've 'successfully' tested a 64GB card before, reformatted to FAT32 and not exfat.
(I also used 64GB cards formatted like that for a couple of my raspberry pi boards.)
But I've never tried storing more than a few gigabytes on any system anyway. Even if you were logging data like crazy for a long time, what would you really do with it all?
FAT32 isn't limited to 32GB, it'll work up to 2TB with single files max. 4GB. Exfat is the factory default above 32GB because it's more suited to larger capacity cards and the SD card controller has to understand exfat format (I think?).
Can anyone else confirm any of the above as working and good information?
Sorry if any of it turns out to be rubbish!

@kevindtimm Up to 16GB should work. I don't know why there is a relatively low SD card limit in the M5Stack hardware (all models). It might be a limit with the ESP32 itself, but I don't know.
My SD card is a 16GB SanDisk Ultra. It was a random selection from my 16GB cards.

@powersoft I got the M5EPD_TTF example running using the GenSenRounded-R.ttf file copied to my SD card. It displays some differently sized flowers, some unicode math symbols and left/right arrows to show top-left down to bottom-right labels.
I removed all the addtional example code to just read the font from the SD card, so the setup starts like this:

void setup()
{
    M5.begin();
    M5.TP.SetRotation(90);
    M5.EPD.SetRotation(90);
    M5.EPD.Clear(true);

    canvas1.loadFont("/GenSenRounded-R.ttf", SD); // Load font files from SD Card
    canvas1.createCanvas(540, 960);
    canvas1.createRender(48, 256);
    ...

I just tried one of my SD cards in my M5Paper, using the factory test firmware from M5Burner. Everything works without any problems.
I copied over a couple of text files in different folders, a jpg and a mp3 (just for the sake of it).
The files in the folders were shown correctly, with all the correct details.
I could also open the text files and jpg by tapping on them to see the text and the picture. It doesn't recognise mp3 files to open them, but it reads the file size correctly.
Don't misunderstand this but, you have plugged the SD card in properly? It is upside down, the pins are facing upwards when you insert it. It is fully inserted so it clicks into place. It needs to be pushed right inside with your fingernail, otherwise it's not really in. Sorry if that's blatantly obvious, but you never know.

@world101 You can just use the files in the ESP32-A2DP project as a start.
I didn't change anything in the arduino library, I just had to change the name of the speaker (obviously) in the bt_music_sender_write example. There's an error in that sample project at the moment as StarWars10 is defined, but the data is actually called StarWars30, just rename it and it should compile.
I had the problem that the original sample played at double speed! I've followed the instructions to create new samples in audacity and export/convert them. Make sure to exactly create 44100 stereo 16-bit PCM data files, convert with xxd and then use TwoChannelSoundData so it plays at the correct speed.