Hello Friends! First time posting, so I wanted to introduce myself. What better way than to tell a tale of curiosity that almost killed the cat... or in this case my brand new Core2.

It all started as I was reviewing the documentation and the schematic. I noticed that the M5Stack Documentation site lists the ATECC608A, which I cant for the life of me find on the schematic. (https://docs.m5stack.com/#/en/core/core2) So my curiosity got the best of me and I decided the best course of action would be to take the Core2 apart to try and find the chip! I mean there are a couple screws on the back, it cant be that bad, right?!

Well, part 1 of my assumption was true. I took the 4 screws on the back off and carefully separated the back from the front. This part was relatively straight forward. The only surprise being to make sure that you catch the EXT board when you separate the parts because it'll come off quick. I sat and marveled at the board. Very clean and very well done. With the help of my cellphone camera, I was able to zoom in close enough to identify all the IC's on the board and the schematic. I should have stopped here, but I didn’t find what I was looking for. It was about then I noticed there were 2 additional screws at the bottom of the board.

If you decided to follow along on my journey. STOP. TURN BACK. DO NOT PASS GO. This is where things start getting sketchy. You should know, I'm no special anyone, I have no tools or expertise that would help on this journey. Just curiosity and sausage fingers. Undoing the 2 screws was pretty simple, but then trying to figure out how to release the main board became problematic. I finally figured out that you have to remove the speaker and the vib motor in order to slide the board back enough to allow it to clear the notch. Once that happened, I figured, "I'm in the clear" so I opened it carefully, but just a little too far. It's then I discovered that the LCD and touch ribbons are now disconnected from the two tiny ribbon connectors. In case you were wondering, the ATECC608A isn’t on the backside of the main board. Besides those connectors were some test pads and the button battery. (It's soldered in, and looked like a MS614).

After a LOT of time very carefully getting the ribbons put back in... which I somehow was able to do (again, see the part about having sausage fingers...) It came time to reassemble. All was going well, thought I had everything back. Reattached the battery, ran though the Factory Test Program and everything worked BUT the vib motor. Shoot. So after disassembling the 2nd time, I found that I hadn’t routed the wires properly and managed to knock the positive side of the motor off of the main board. Thankfully, the only tool I did have handy was a soldering iron with a needle tip. After some creative use of a cellphone zoom and a helping extra hand, I managed to get everything reconnected, reassembled and everything passed the factory test program on the next boot. YAY!

Moral of the story... don't take your Core2 all the way apart (or probably apart at all...)

Addendum: After reading the datasheet for the ATECC608A it very clearly calls out that "the part mark for all crypto devices is intentionally vague." So going back though the pictures I took, there appears to be a chip that matches the description just to the side of the USB-C port. I'm not sure, but the pad count is correct and its the right size so ** shoulder shrug emoji here ** ?

If anyone has any information about where this shown on the schematic or if you can use the chip at all from code, please let me know!

Nice to meet you! Thank you and enjoy your Core2!

Just to close the loop for anyone from the future...

Here's the steps I took to resolve this:

1. Uninstall / Cleanup / Restore to macos Mojave default python installation. (Which is v2.7.16 as noted above.) This was a pretty intensive step. The short breadcrumb for anyone else:

Dont touch the mac system python installs located at:
/System/Library or
/usr/bin

helpful stack overflow post for uninstalling python

But in the end, from what I could find Mojave doesn't include pip by default, and easy_install is depreciated so we had to go to step 2.

2. brew install python Today in Dec 2020 this will install 3.9.0. ((Python 2.7 has been long depreciated))[Also note pip is currently installed with this version of python]
3. At this point if you type python --version you will still get: 2.7.16
4. While reading the ESP-IDF toolchain instructions, I noticed the following command:
   ln -s /usr/local/bin/python3 /usr/local/bin/python
   This setup a symlink to the python3 symlink also installed by brew. (Seems kind of hacky, but technically works...) I also had to do: ln -s /usr/local/bin/pip3 /usr/local/bin/pip which cleaned up any remaining issues making pip work. (Biggest issue being me forgetting to type pip3)
5. After restarting my terminal, running python --version I now get: 3.9.0
6. With my new python env working as expected, I fired up ardunio IDE and one of the Core2 examples, and went to verify to see if my issues went away... And I still had the issues above in my original post.
   6b. At this point I tried a ton of other things, most notably redoing everything by installing pyenv and trying to set the global env to 3.9, but none of those steps worked...
7. I went back through the troubleshooting steps above, had the expected correct outcomes. Even ran the esp-tools.py directly and didnt have any issues importing serial or anything else.
8. I believe the actual issue is the first line in the esp-tools.py:

#!/usr/bin/env python

Which I believe is what is forcing the ardunio IDE to use the default MacOS python version. (See note in #1 about this being the protected default python that we shouldnt touch.)
9. Just as a test, I changed that line to be:

#!/usr/bin/env python3

Once I reopened Ardunio, this worked and verified without any issues.

10. However, I feared that if I ever updated the board definitions I would forget about this change and it would all break again. So I followed @lydericc instructions above. (Thank you!) You really shouldnt do this, but it's the only way to make it "work" with everything else out of the box. Specifically the following line (Step 2 in the post above):

sudo pip3 install --target /Library/Python/2.7/site-packages pyserial

This installed the required serial module and fixed the remaining issues.

I'm not sure I like the solution, but it is the only thing that has made it work. The "correct" fix would be to have esp-tool.py use the installed default python version instead of the specific one installed at /usr/bin.

Finally, as with all things in life, there is already an xkcd for this: https://xkcd.com/1987/

Maybe I'll open an issue with the esp-tool or Ardunio IDE and see what happens, but I dont believe this has anything to do with M5stack tools. Thanks for all who helped! (@Zontex & @lydericc )

I'm still hopeful that some day I will get an answer to my questions!

I've emailed support and also not received an answer but I'm going to keep checking every day!

@pensive

Thank you for running that test! I thought that's how it worked but didnt have time to get around testing it. The idea I had was to integrate either the time on or approx consumption and store it using the "preferences" library. The library saves whatever to the non-volatile memory so you wouldnt need the SD card. There was a write up of the libaray on the forums here:

https://community.m5stack.com/topic/1496/storing-settings-in-the-memory-of-the-core

So the two ideas:

1. track how long the device has been on, update a preference with the time, subtract time on from the 5 hours 40 mins to get time remaining. It wont always be accurate, but probably close enough for most uses.

2. Calculate the current consumption based on screen/wifi/bluetooth/etc being on, integrate all that and compare to total mah of the battery. (This would have a lot of factors, but could probably get you closer if you figured all them out.)

I think the first one is the "easiest", do you have any thoughts?

This is amazing! Great work! Your website is also packed with great information! Welcome to the Community!

I dont have this unit, but if you look at the following github where I believe the library is used from there are calibration instructions there:

https://github.com/bogde/HX711/

I'd start with that and see what happens.

Good Day!

I posted this under the core2 product page, but will post here also since this chip exists in more than just the Core2. Specifically:

1. Why doesnt the Invensense website even list this chip? Is it custom made for M5Stack?

2. Has anyone figured out how to properly set the offsets? I found a library that measures them and then applies them externally but not actually setting them on the chip. (For example, register 19&20)

3. I was trying to find the chip on the website to determine if there were any further application notes or suggestions. Other Chips like the MPU-6050 have a DMP (Digital Motion Processor) component that would be great for gesture offloading. It doesn't appear this chip has this based on the datasheet listed on the M5 website)

4. Any Tips on calibrating these? Mine has a lot of noise when laying on a flat surface which I'm trying to reduce.

5. While reviewing the datasheet, it appears that the XA_OFFSET registers are 15bit signed ints not 16. It appears that most of the popular libraries written for the 6050, 9250 have this mapping incorrect.

Just to close the loop for anyone from the future...

Here's the steps I took to resolve this:

1. Uninstall / Cleanup / Restore to macos Mojave default python installation. (Which is v2.7.16 as noted above.) This was a pretty intensive step. The short breadcrumb for anyone else:

Dont touch the mac system python installs located at:
/System/Library or
/usr/bin

helpful stack overflow post for uninstalling python

But in the end, from what I could find Mojave doesn't include pip by default, and easy_install is depreciated so we had to go to step 2.

2. brew install python Today in Dec 2020 this will install 3.9.0. ((Python 2.7 has been long depreciated))[Also note pip is currently installed with this version of python]
3. At this point if you type python --version you will still get: 2.7.16
4. While reading the ESP-IDF toolchain instructions, I noticed the following command:
   ln -s /usr/local/bin/python3 /usr/local/bin/python
   This setup a symlink to the python3 symlink also installed by brew. (Seems kind of hacky, but technically works...) I also had to do: ln -s /usr/local/bin/pip3 /usr/local/bin/pip which cleaned up any remaining issues making pip work. (Biggest issue being me forgetting to type pip3)
5. After restarting my terminal, running python --version I now get: 3.9.0
6. With my new python env working as expected, I fired up ardunio IDE and one of the Core2 examples, and went to verify to see if my issues went away... And I still had the issues above in my original post.
   6b. At this point I tried a ton of other things, most notably redoing everything by installing pyenv and trying to set the global env to 3.9, but none of those steps worked...
7. I went back through the troubleshooting steps above, had the expected correct outcomes. Even ran the esp-tools.py directly and didnt have any issues importing serial or anything else.
8. I believe the actual issue is the first line in the esp-tools.py:

#!/usr/bin/env python

Which I believe is what is forcing the ardunio IDE to use the default MacOS python version. (See note in #1 about this being the protected default python that we shouldnt touch.)
9. Just as a test, I changed that line to be:

#!/usr/bin/env python3

Once I reopened Ardunio, this worked and verified without any issues.

10. However, I feared that if I ever updated the board definitions I would forget about this change and it would all break again. So I followed @lydericc instructions above. (Thank you!) You really shouldnt do this, but it's the only way to make it "work" with everything else out of the box. Specifically the following line (Step 2 in the post above):

sudo pip3 install --target /Library/Python/2.7/site-packages pyserial

This installed the required serial module and fixed the remaining issues.

I'm not sure I like the solution, but it is the only thing that has made it work. The "correct" fix would be to have esp-tool.py use the installed default python version instead of the specific one installed at /usr/bin.

Finally, as with all things in life, there is already an xkcd for this: https://xkcd.com/1987/

Maybe I'll open an issue with the esp-tool or Ardunio IDE and see what happens, but I dont believe this has anything to do with M5stack tools. Thanks for all who helped! (@Zontex & @lydericc )

When I run that command I get:

python --version
Python 2.7.16

And when I try to import serial, I get the same error as with the esptool script:

Python 2.7.16 (default, Jan 27 2020, 04:46:15) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named serial

So it appears that "pip" is symlinked to my python3 install, but "python" is still linked to the v2.7.16 default mac install.

Thanks again for your help, will wait for an update!

When I did that I got the following message:

pip install pyserial
Requirement already satisfied: pyserial in /usr/local/lib/python3.8/site-packages (3.5)

So it appears that my system is using 3.8 already?

I appreciate your help in trying to figure this out!

So I tried your recommendations as suggested:

1. Installed pyserial. Python3 was already installed.

'pip3 install pyserial
Collecting pyserial
   Using cached pyserial-3.5-py2.py3-none-any.whl (90 kB)
 Installing collected packages: pyserial
  Successfully installed pyserial-3.5

2. Removed 1.0.5 of M5stack from board manager, restarted arduino IDE, Installed 1.0.6, restarted IDE. Get the following error when trying to compile the factory test program:

Traceback (most recent call last):
  File "/Users/User1/Library/Arduino15/packages/m5stack/tools/esptool_py/3.0.0/esptool.py", line 39, in <module>
    import serial
ImportError: No module named serial

It appears that the v1.0.6 version of the board manager is not working. I believe its related to switching to esptool 3.00. The specific issue I'm running into is a compile error on line 39 of the esptool.py that is installed by the v1.0.6 board version, saying "can't import serial"

I tried to look deeper into the issue, it appears to be quite the ordeal with the esptool.py (quite a few issues listed in the script...) but it appeared the fix was to update the install to use pyserial.

I am using the latest version of Arduino 1.8.13 on Mac OS 10.14.6 . When I downgrade to 1.0.5 (v2.6 of esptool...) all of my issues disappear. I would open an issue on github but there didnt seem to be an appropriate place. Thank you!