#mchip curiosity

1 messages Β· Page 1 of 1 (latest)

calm elbow
#

@night gazelle Hi Ross here is a thread

#

i will look at the flash chip on this xplained board and see if i can get the board working in any way, including with INTERNAL-FILESYSTEM.

stark reef
#

A clue I could use is which pins on the Xplained board I can use for a serial console? That would help me expedite my testing.

calm elbow
#

@Ross: eightycc is working on fixing the chip support for the flash chip.

calm elbow
stark reef
#

Good resource. My work on the flash problem is trapped in my big box until the power comes back on, so I'm blocked until then.

#

My battery is down to 15%, so you probably won't here from me for a couple of hours...

calm elbow
#

@night gazelle do you have a regular same54 xplained board handy to try things on? Is it the blue or red one? I think it changed flash chips during the Great Chip Shortage

#

hmm, chip on mine is N25Q256, a micron flash chip.

#

in any case, I will try to get a no-flash-chip version running on this board

night gazelle
calm elbow
#

OK, great, this is working, with INTERNAL_FLASH_FILESYSTEM = 1. I had to do CIRCUITPY_ULAB = 0 to make it fit -- no big deal

#

i can email you the UF2 and you can try it on the new board. The LED's are in the wrong place, but the USB is the same, I assume, so it should at least come up.

#

if it doesn't come up, then the hw may need some debugging

night gazelle
#

Just flashed the uf2 you sent.
After flashing I pressed the reset button. Windows explorer did not see a drive.
However Device Manager found COM33.

I opened COM33 in TeraTerm and saw this message:

rn_image_picker_lib_temp_3a41032b-41bd-44bb-9ff2-d2666c94442e.jpg
calm elbow
#

that is absolutely correct

#

but you should see a CIRCUITPY drive

#

in the window, hit ENTER and type ctrl-D. Does it just rstart? Do you see any errors?

#

Try this:

import os
os.listdir()
#

should list a few files

#

did you find an e54 xplained board?

#

do you have any other circuitpython boards?

#

we want to see if this is a Windows problem or a build or board problem.

#

since serial came up, I suspect Windows. Various utility programs can interfere with seeing the drive. Hence, worth trying a more vanilla CircuitPython board

night gazelle
#

No errors.

But I don't see a CIRCUITPY drive

rn_image_picker_lib_temp_01f35d34-4035-4296-9e81-650e00142fd0.jpg
calm elbow
night gazelle
night gazelle
calm elbow
#

hmmm... did you round up an e54 xplained board yet? Try the .uf2 on that one. Do you have a Linux or Mac system to try it on as well?

night gazelle
#

I think I found the culprit.

Will work on getting it whitelisted.

rn_image_picker_lib_temp_61837591-475e-4764-a8bb-6f0090e7d9b0.jpg
calm elbow
#

@night gazelle I built from your repo, development branch. I had to fix one typo: #define DEFAULT_SPI_BUS_SCK (&pin_PA17) had PBA17. But then I loaded it on the xplained 54 board and it came up with CIRCUITPY and serial: Adafruit CircuitPython 9.2.6-18-g0f9462f35c-dirty on 2025-04-09; Microchip Curiosity CircuitPython Nano with same51j20

#

I'll email you the UF2

night gazelle
#

I put in an mchp internal request to have the flash serial numbers whitelisted so windows can see the CIRCUITPY drive.
Once that's done I can start validating the board with the SST26VF016B while support for the SST26VF016B is being figured out.

Thanks very much!

calm elbow
#

great! did the second build I emailed work for you at all?

night gazelle
#

I had to leave for an appointment, I'll test it in the morning

night gazelle
#

I can see the CIRCUITPY drive now.
The second build appears to work, have only just started testing

calm elbow
night gazelle
#

@calm elbow I just realized that my pins.c file is missing the objects for I2C, SPI, and UART.

Can I email you an updated pins.c file for a new build?

Alternatively, could you send me instructions for building without the QSPI flash for testing purposes?

night gazelle
#

@calm elbow I just pushed the pins.c changes to the development branch of curiosity_circuitpython_nano

calm elbow
#

I pulled your changes. I will submit a PR to your repo to show you the changes.

#

I'm rebuilding and will email the .uf2

#

These are the only changes I made:

# 
ports/atmel-samd/boards/microchip_curiosity_circuitpython_nano/mpconfigboard.h 
index 0188cd9b51..58c53a8f47 100644
@@ -19,7 +19,7 @@
 #define DEFAULT_I2C_BUS_SCL (&pin_PB31)
 #define DEFAULT_I2C_BUS_SDA (&pin_PB30)
 
-#define DEFAULT_SPI_BUS_SCK (&pin_PBA17)
+#define DEFAULT_SPI_BUS_SCK (&pin_PA17)
 #define DEFAULT_SPI_BUS_MOSI (&pin_PA16)
 #define DEFAULT_SPI_BUS_MISO (&pin_PA18)
 

 ports/atmel-samd/boards/microchip_curiosity_circuitpython_nano/mpconfigboard.mk 
index 666cec8ede..b1b671b003 100644
@@ -6,7 +6,8 @@ USB_MANUFACTURER = "Microchip Technology Inc"
 CHIP_VARIANT = SAME51J20A
 CHIP_FAMILY = same51
 
-QSPI_FLASH_FILESYSTEM = 1
+INTERNAL_FLASH_FILESYSTEM = 1
+#QSPI_FLASH_FILESYSTEM = 1
 EXTERNAL_FLASH_DEVICES = "SST26VF016B"
 LONGINT_IMPL = MPZ
calm elbow
#

I can't submit a PR after all easily, but the changes above are it.

night gazelle
#

After flashing the new uf2 firmware I'm still getting I2C invalid pins errors:
ValueError: Invalid pins
I'm using the REPL and putting in the following code:
import busio
i2c = busio.I2C(board. SCL, board. SDA)

I'm guessing I have made an error in pins.c but I can't seem to see where I've gone wrong.

calm elbow
#

The problem is not in pins.c. This is a SAME54P20A, is that right?
So the problem is in mpconfigboard.mk, which has:

CHIP_VARIANT = SAME51J20A
CHIP_FAMILY = same51

but it should be:

CHIP_VARIANT = SAME54P20A
CHIP_FAMILY = same54
night gazelle
#

It's a SAME51J20A

PXL_20250411_013759430.jpg
calm elbow
#

oh, sorry, I thought it was the same chip as the xplained board

night gazelle
#

It's mostly modeled on the Feather M4 CAN

calm elbow
#

there is something odd for the the SAME's, then I think, because I can get PB31 and PB30 to work on the Grand Central M4, which is a SAMD51P20A.

#

let me look at some other boards for a minute

#

ok, you have chosen PB31 for SCL and PB30 for SDA. I think that works for SERCOM7 (only on the P-series chips, right?), but not for SERCOM5). It does work if I flip it around:

>> import microcontroller,busio
>>> i2c = busio.I2C(microcontroller.pin.PB30, microcontroller.pin.PB31)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: No pull up found on SDA or SCL; check your wiring
#

as opposed to Invalid pins with the pins flipped

#

We have this data in peripherals/sam_d5x_e5x/pins.:

PIN(PB30, EXTINT_CHANNEL(14), NO_ADC, NO_ADC, NO_TOUCH,
    #ifdef SERCOM7
    SERCOM(7, 0),
    #else
    NO_SERCOM,
    #endif
    SERCOM(5, 1),
    TC(0, 0),
    TCC(4, 0),
    TCC(0, 6));
#endif
#ifdef PIN_PB31
PIN(PB31, EXTINT_CHANNEL(15), NO_ADC, NO_ADC, NO_TOUCH,
    #ifdef SERCOM7
    SERCOM(7, 1),
    #else
    NO_SERCOM,
    #endif
    SERCOM(5, 0),
    TC(0, 1),
    TCC(4, 1),
    TCC(0, 7));
#endif
#

the pads are reversed for SERCOM7 vs SERCOM5

#

I'll double-check that with the datasheet (which is where this came from)

#

yup

#

make sense to you? Does this board have silkscreen yet for SCL/SDA?

night gazelle
#

On my way home, will check when I get there

night gazelle
calm elbow
#

so schematic and silk will need revision, but I assume that's part of the dev process here

#

in other thread #1359865196645978404 message, @stark reef noted some unusual things about the chosen flash chip he is trying to get to work. If he has questions, would you be able to refer him to a support enginner who's experienced with the chip? thanks

night gazelle
calm elbow
#

we'd have to look at the datasheets

#

adding a new chip is easy, if it's like other ones

#

q is whether the 32 is like the 16 or like the 64

night gazelle
#

@calm elbow I have been going through the I2C pins issue, along with my spreadsheet in which I allocated SERCOMs and pins.

I had allocated SERCOM7 for I2C, but I can't figure out where in the files I need to declare that?

night gazelle
#

I just swapped the default SCL & SDA pins in mpconfigboard.h

#

Also just swapped PB30/31 so that SDA is PB31 & SCL is PB30

calm elbow
#

the choice of SERCOM is dynamic

night gazelle
#

Something weird is happening. The CIRCUITPY drive is not appearing. I noticed it first this morning, then I disconnected and reconnected the board and it was fine.

Now it's doing it again, and no matter what I do the CIRCUITPY drive doesn't appear.

What I've tried:
Rebooting PC.
Double click reset button, then single click reset button.
Disconnect and reconnect board.
Double click reset button and reflash UF2 @calm elbow sent yesterday.

It shows in Device Manager, but nothing in TeraTerm. I confirmed SentinelOne is NOT blocking it

calm elbow
#

it could be crashing early. If you're still seeing the BOOT drive then presumably the bootloader is OK.

night gazelle
#

I just clicked reset to get into safe mode, that seems to work

calm elbow
#

were you editing some program that was testing a feature? normally a hard crash would send it into safe mode with a reason

#

CIRCUITPY might be corrupted. You can do

import storage
storage.erase_filesystem()

to get it to erase and reformat CIRCUITPY

night gazelle
#

I was doing the board_test for I2C earlier today

night gazelle
calm elbow
night gazelle
#

Just found the pin names. Doh!

calm elbow
#

BoardTest is a recent thing and may have bugs, also.

#

we don't use it on a regular basis (maybe we should)

#

... well, not that recent, i see

night gazelle
#

I'm not using MISO for the LCD, as a result I'm getting an error that the MISO pin isn't defined.

calm elbow
#

that SPI test is expecting to r/w to/from an EEPROM chip. If there's no available MISO pin for that SERCOM, then I'm not sure how you would test it

#

unless you set up another board to receive the MOSI signal and vet it

#

or you could do a loopback to another SPI device on the board, if you have the pins

night gazelle
#

I tried connecting it to the LCD and a logic analyzer and running basic LCD code. But it crashes and I have to enter safe mode manually & erase the filesystem to get it back 😡

calm elbow
#

One thing I would suggest is not putting test programs in code.py. Instead invoke them manually from the REPL with import whatever.py. Then you don't have to get into safe mode to prevent a crash

night gazelle
#

@calm elbow I tried setting up the build env again so I can build locally.
It (again) produces a UF2 but it doesn't show CIRCUITPY drive.

On GitHub I have updated the development branch of my fork. When you have time, could you please build it and send to me?

calm elbow
# night gazelle <@329766224093249548> I tried setting up the build env again so I can build loca...

When I compile the latest development commit, I get errors:

n file included from ../../shared-bindings/board/__init__.h:9,
                 from boards/microchip_curiosity_circuitpython_nano/pins.c:7:
boards/microchip_curiosity_circuitpython_nano/pins.c:75:47: error: 'board_sdspi_obj' undeclared here (not in a function); did you mean 'board_spi_obj'?
   75 |     { MP_ROM_QSTR(MP_QSTR_SDSPI), MP_ROM_PTR(&board_sdspi_obj) },
      |                                               ^~~~~~~~~~~~~~~
../../py/obj.h:348:24: note: in definition of macro 'MP_ROM_PTR'
  348 | #define MP_ROM_PTR(p) (p)
      |                        ^
boards/microchip_curiosity_circuitpython_nano/pins.c:76:48: error: 'board_lcdspi_obj' undeclared here (not in a function); did you mean 'board_spi_obj'?
   76 |     { MP_ROM_QSTR(MP_QSTR_LCDSPI), MP_ROM_PTR(&board_lcdspi_obj) },
      |                                                ^~~~~~~~~~~~~~~~
../../py/obj.h:348:24: note: in definition of macro 'MP_ROM_PTR'
  348 | #define MP_ROM_PTR(p) (p)
night gazelle
#

I was trying to create an object for the SPI bus that is used only for the SD card.
Similarly for the lcdspi object, that SPI bus is used only for the LCD

#

Is there a way to create an object for each of those?

calm elbow
#

yes, I'll do it and send you something, or update the PR

#

do you want a plain board.SPI() object also?

#

and are the "SPARE" pins labelled that on the board?

#

also the CAN pins are in there twice. I'll fix that

night gazelle
night gazelle
calm elbow
#

what are the pins for that one (SCK, MOSI, MISO, and I guess CS also)

#

so the SPARE pins are used for the third non-specialized SPI bus?

night gazelle
#

Spare0 PB00
Spare1 PB01
Spare2 PB02
Spare3 PB03

night gazelle
calm elbow
#

which ones are you assigning to which SPI functions?

night gazelle
calm elbow
#

still working on this. no problem, just a lot of details

night gazelle
#

No rush, I'm heading home

calm elbow
#

I'll check to see that it at least comes up on the xplained board

#

I am changing the names slightly to conform to some naming conventions (SD_SPI instead of SDSPI). You can look in the code or do import board; dir(board) to find the names

calm elbow
#

OK here is the build. It does come up. I had to swap the SCL and SDA for I2C to get I2C to work. We talked a bit about this before. The SAME51J only has six SERCOMS, 0-5, and the SERCOM7 you chose for I2C (in the screenshot above) does not exist on this chip.

If you flip SDA and SCL, then you can use one of available SERCOM's. However, Then there's a conflict between board.SPI() and board.I2C() .you can't instantiate both, because there's no way to allocate the SERCOMs to get both to be available.

I can't remember, do you have any spare pins to make this work out?

In any case I will push these changes to the PR.

πŸ“Ž firmware.uf2
night gazelle
#

@calm elbow can you please advise which branch this was built from?
I'm trying to understand better where I went wrong

calm elbow
#

I can push to your branch because you submitted it as a PR, and with that usually comes permission for repo maintainers like us to push to your PR branch.

night gazelle
#

I did git pull, but I didn't see your changes. Trying to figure out what I've done wrong 😡

PXL_20250429_170651013.jpg
calm elbow
#

show me what git status says

night gazelle
calm elbow
#

The first line printed by git status will be what branch you're one. What are the first two lines?

#

you need to update submodules:

#

I use this alias, but you can just paste the command

alias gitsubupdate='git submodule sync --quiet --recursive && git submodule update --init --filter=blob:none'

I'll email it to you

night gazelle
#

On branch main
Your branch is up to gate with 'origin/main'

calm elbow
#

you need to git checkout development, and then do git pull

#

the PR uses the development branch. Don't do development on main. Keep main the same as upstream adafruit/circuitpython.

#

then do the gitsubupdate alias if there are submodules that need updating

#

"modified content" above

night gazelle
#

When I do git checkout development I get error: pathspec 'development' did not match any files known to git

calm elbow
#

what does git remote -v say?

night gazelle
calm elbow
#

you are in a clone of the adafruit/circuitpython repo. You are not in your own repo. You should be in a directory whose top-level is curiosity_circuitpython_nano

night gazelle
#

I think I've been using a cloned directory the whole time.
So I should create a curiosity_circuitpython_nano directory and git pull from there?

calm elbow
#

you were definitely working in that at some point

#

maybe you never had it on your dev machine? Were you doing all the work on the github website?

#

you want to do git clone https://github.com/ross-satchell/curiosity_circuitpython_nano

#

in your homedir or somewhere (not inside where you are now0

#

you don't need to create a directory before you clone. git clone will create it

night gazelle
calm elbow
night gazelle
#

It would probably explain why my builds never worked

night gazelle
#

When I run boardtest_gpio I'm now getting an error that was not on previous builds.
Pin D4 is not used for anything else 😡

PXL_20250429_175944884.jpg PXL_20250429_175923254.jpg
night gazelle
#

I have just tested that I can blink pin D4 manually successfully

calm elbow
#

this is odd; D4 is not aliased to some other pin. What does your code.py print before it gets the backtrace? (It's scrolled up and I can't see the list of pins it printed)

night gazelle
#

I just ran it again and now it works πŸ€”

calm elbow
#

could you show me the list of pins it prints anyway?

#

are you using my build or your own build?

night gazelle
night gazelle
calm elbow
#

The D4 in use would be because somehow the DigitalInOut didn't get deinited. But that should happen automatically. It's possible you made the PR against a commit on main that was a while ago and there was some bug that has since been fixed. We are doing a lot of changes for 10.0.0 and there has been some churn. I can bring your branch up to date and rebuild. Was it just that one time?

#

rebuild, but I don't see any changes that would have anything to do with this

#

I'll say again that the board-test library was done a while ago, and is not really used, so it's not that comprehensive. So though it will be helpful at vetting, it won't be a complete test (as a simple example, your SPARE_n pins are not being tested).

night gazelle
night gazelle
#

@calm elbow I've been testing all day.
So far I have successfully tested:
I2C working with BME680, BLE_UART with loopback, DEBUG_UART with loopback, A0-A5 analog pins, D0-D7,D13,LED digital pins, SD_SPI using boardtest.
Did a test of LCD_SPI, can see the data on logic analyzer, but display not yet working.

calm elbow
night gazelle
#

I'm going to test the backlight and display reset controller tomorrow.
But big strides today! Thanks for all your continuing help, it's greatly appreciated!

night gazelle
#

@calm elbow could I get a sanity check?

I'm trying to use AnalogOut for the DAC pin. But I'm getting nothing out.

I've checked the schematic and pins.c match (pin PA02). I've also tried directly using microcontroller.pin.PA02

It doesn't seem that anything else is using pin PA02.

Here's the code, pins.c and schematic

PXL_20250430_201944102.jpg PXL_20250430_201956954.jpg PXL_20250430_202018391.jpg
calm elbow
#

The values range from 0 to 65535. Is that what you’re using?

#

Your screenshot says PA05, not 2

#

I guess you know that

#

I can’t get to the data sheet right now

night gazelle
calm elbow
#

Try it on a known good board, maybe. But no reason it should not work

night gazelle
#

PA02 & PA05 are both DAC pins

PXL_20250430_203550597.jpg PXL_20250430_203538943.jpg
night gazelle
night gazelle
#

@calm elbow Having an issue with the board.I2C object.
If I instantiate it using:
i2c = board.I2C()
I get the error invalid pins.
If I instantiate it using:
i2c = busio.I2C(microcontroller. pin.PB30, microcontroller. pin.PB31)
It works as expected.

However mpconfig.h shows the pins are correct:

PXL_20250506_184421012.jpg
stark reef
night gazelle
stark reef
night gazelle
#

I also just tried it with the specific pins and still got invalid pins error

PXL_20250506_195523670.jpg
stark reef
# night gazelle

That it's failing for both cases indicates that a resource assignment to one of the I2C pins isn't happening as expected. I'm not familiar with the SAMD pin mux'es, but Dan told me that they have some built-in limitations. I'm going to grab the datasheet and have a look and compare it to what our SERCOM code is doing.

night gazelle
#

I just rebooted my Windows machine again (that often solves weird problems).

Now
i2c = board.I2C()
works as expected

πŸ₯΄

stark reef
#

Maybe it was my threat to read the datasheet? πŸ€·β€β™‚οΈ

night gazelle
#

I just re-tried the program I was trying to run earlier that uses the APDS9960 Gesture sensor breakout.
Again I'm getting the invalid pins error.

πŸ“Ž code.py
#

There's something weird going on. I think maybe I should bring in my own laptop tomorrow and try on that.

calm elbow
#

Scott fixed a deinit issue which may or may not have anything to do with this. You could merge or rebase from adafruit to get the changes. I

stark reef
#

Ross, let me know how it goes. I've spotted something in our code that might be affecting you. Or not.

night gazelle
#

I had to leave for an appointment. I'll have another crack at it in the morning

night gazelle
#

I had previously been having problems producing builds that would get me to the REPL (Dan is aware of this).
I had fixed some things that may have been contributing to that. Just made a new build following Dan's guide "Building CircuitPython".

Looks like there's something screwy still happening as I can see the COM port in Device Manager and can open a serial terminal to that port.
However the REPL never comes up, even if I try to go into safe mode when booting.

stark reef
#

I don't see anything in your PR that would cause REPL problems. Is the CIRCUITPY MSC device appearing?

night gazelle
#

MSC?

stark reef
#

Mass Storage Device Class, it's the USB endpoint that serves up the CIRCUITPY image.

night gazelle
#

No, it was not coming up.

But something weird did happen after trying to not in safe mode. I went to get a coffee and when I came back (~10 mins later) CIRCUITPY drive was there and terminal stated it was in safe mode.

I pressed reset button to exit safe mode and it disappeared again. To be sure I waited another 10 mins but nothing was coming up

stark reef
#

I'm thinking that it might be your security software. See if anything is showing up in Device Manager.

night gazelle
#

The COM port shows up in Device Manager. I confirmed Sentinel One (security sw) is not blocking it (have had that issue in the past)

stark reef
#

I'm out of ideas for the moment. I'll be AWK for lunch until about 1PM PST.

stark reef
#

When REPL over USB isn't working, it's possible to bring REPL to a UART and connect it using an external UART to USB adapter. Have you tried this?

night gazelle
stark reef
#

Let me know if you'd like to try it. I can fill you in on what you'll need and how to proceed.

night gazelle
stark reef
#

To use a UART for REPL you'll need a serial to USB adapter. Something like this: https://www.adafruit.com/product/284. If you don't have one on-hand, a Raspberry Pi Pico flashed with debugprobe will work. That's what I usually use.

In your board's mpconfigboard.h add these lines:

#define CIRCUITPY_CONSOLE_UART_RX   (&pin_Pxxx)
#define CIRCUITPY_CONSOLE_UART_TX   (&pin_Pxxx)
#

Fill in the pin numbers you'll use for the UART. Probably PA23 and PA22. When the build sees these defines it will automatically create an additional serial console with the UART muxed to these pins and start it early in the boot process. The default data rate is 115200.

night gazelle
#

I'm currently testing the UART for the BLE module we are using. I'm using the last build that @calm elbow sent me.

I have noticed that I can't toggle the BLE_CLR pin (PA14). I have successfully tested continuity between MCU pin PA14 and the BLE_CLR pin.

I have checked on both logic analyser and scope.

Does having a non-Dx name (eg. D0, D1, etc) preclude it from being able to be used as a digital IO pin?

night gazelle
#

Nevermind, I found a short to GND from BLE_CLR

night gazelle
#

@calm elbow after having plenty of problems building in WSL (I wonder if all the security stuff on our laptops is causing issues), I figured I would try a personal Ubuntu 24.04 laptop.

calm elbow
#

sounds good; i was wondering if you could get a dispensation

night gazelle
#

@calm elbow I'm seeing some weird behavior with using the board.I2C() object.

Usually when I run the simple I2C scanner code found here: https://learn.adafruit.com/circuitpython-essentials/circuitpython-i2c#find-your-sensor-2985153-11

I will get back the address of whatever I2C device/s I have connected.

But occasionally I get the error:
Value Error: Invalid Pins

If I double click the reset button and go into bootloader mode, then click the reset button to return to CIRCUITPY it starts reading off the I2C addresses again.

Trying to figure out how to fix this, any suggestions?

CircuitPython Essentials

The next step in learning CircuitPython.

calm elbow
night gazelle
#

I find when it gives the Invalid Pins error, if I reload using CTRL-D, it just keeps happening.

But instead if I put it in bootloader mode and wait a few seconds before pressing reset again, it sometimes works.

No I2C devices except for APDS-9960

calm elbow
#

what is the sequence of events that leads to Invalid pins? Are you running the same code.py over and over? Is that code.py the I2C scan example?

stark reef
#

I recall seeing a place where CP isn't resetting I2C as completely as it does SPI that might be causing the invalid pins exception. Let me take a look at the code...

night gazelle
#

Initially I was trying to test APDS_Gesture_Audio. Py (attached & known working code on M4 feather express, should be easy to get working on SAME51) and was getting the invalid pins error.

So I ran the I2C scanner code and found it was also returning the same error.

I just found that pressing the reset button sometimes works to correct the error.

πŸ“Ž APDS_Gesture_Audio.py
stark reef
#

Called away for a few minutes, I'll keep looking when I return.

stark reef
#

@calm elbow @night gazelle I think I've found it again. For the SAMD, there's a SERCOM associated with the pin. The SPI flavor of de-init marks the SERCOM as eligible for reset, but the I2C doesn't. I'll cook up a PR for it. I'm not sure how to build for your board, but maybe Dan can do that.

night gazelle
#

@stark reef @calm elbow Just for reference, the MCU is a SAME51J20A, in case that changes things

calm elbow
#

@night gazelle if you put i2c = board.I2C() before spi = board.SPI() do you still see the problem? I wonder if they are trying to use the same SERCOM. The displayio.release_displays() should prevent that problem. Or it could be due to running APDS_Gesture_Audio.py and then the scanner (or vice versa), without a ctrl-D in between

#

@stark reef thinks he's got a fix, but I'd like to be able to reproduce the problem.

night gazelle
#

I call release_displays()
Then instantiate the I2C object and the APDS9960 object.

I've attached the code:

πŸ“Ž code_1.py
calm elbow
#

so if you run this, type ctrl-D, and then run it again, do you reliably get Invalid pins?

night gazelle
night gazelle
calm elbow
#

do you mean just pressing reset (as opposed to going into the bootloader) still produces invalid pins?

night gazelle
calm elbow
#

i have a meeting in a couple of minutes but will try to reproduce tonight or tomorrow.

night gazelle
#

Bootloader seems to make no difference

stark reef
#

@calm elbow Another possibility is that the zero segment isn't getting zeroed on reset. I followed the code through the bootloader, but its reset vector zeroes the zero segment belonging to the bootloader, not CircuitPython's. There must be a crt0 or similar that's doing the zeroing for CP's zero segment, but I haven't found it.

calm elbow
#

On samd, the zeroing happens in, I believe, for example, asf4/samd21/gcc/gcc/startup_samd21.c , asf4/same51/gcc/gcc/startup_same51.c, etc. in Reset_Handler

#

if that is not being called we should do something about it

stark reef
#

@calm elbow I've followed the entire bootrom reset process, and learned quite a bit in the process. There are actually two instances of startup_same51.c compiled into the flash: The first is part of the bootloader (uf2-samdx1) that begins at 0x0000, and the second is compiled into the CP image that begins at 0x4000.
A reset invokes the bootloader instance of Reset_Handler which clears the bootloader's zero segment (among a few other early chores) and enters main(). main() performs some chip initialization, then invokes check_start_application(). This gets the address of CP's Reset_Handler from +4 in its vector table (0x4004) and branches to it. This clears CP's zero segment and starts up CP at its main().
So, there's nothing broken in zero segment zeroing that I can see.

calm elbow
calm elbow
#

@night gazelle I have been trying to reproduce the "Invalid pins" error on some other boards, to no avail. Could you describe an exact sequence of what you did to get that error: which programs did you run, in which order, and did you type ctrl-D in between?
I am trying the I2C scanner from here https://learn.adafruit.com/circuitpython-essentials/circuitpython-i2c#find-your-sensor-2985153-11, and also your APDS_Gesture_Audio. Py. Were they stored as code.py or as something else that you imported manually?
If you can show a screenshot of what you did, that might help as well.

I don't have an SAME board except for the XPlained Pro, which is a SAME54P20. It is not clear to me whether this issue is SAME-specific or . I can get a https://www.adafruit.com/product/4759, which has a SAME51J19. Or do you have a spare of the curiosity board that you could send me, if needed?

But the first order of business is to try to reproduce exactly what you did and get "Invalid pins'. Did you ever see that issue when you were testing on the non-curiosity board?

night gazelle
night gazelle
#

@calm elbow what's your shipping address?

calm elbow
#

I DM'd you with the address. Did you get that/

night gazelle
#

Got it, thanks!

calm elbow
#

great!

#

this should make things a lot easier for both of us!

calm elbow
#

@night gazelle I got a delivery notice (by Tuesday). Thanks!

calm elbow
#

@night gazelle board just arrived, a day early. I pushed the headers into the staggered holes πŸ™‚ Cute idea. Maybe I will solder anyway. I'll see if I can reproduce the problem with a build from your fork and branch.

night gazelle
#

I realized on Sunday that the board I still had was running the "dirty" build. (I'll go give myself an uppercut!). Still would like to get confirmation from you.
I flashed the newest build you had sent and the invalid pins error went away.
I did still notice that sometimes the CIRCUITPY drive becomes unresponsive. Usually a reset fixes it, but the Feather M4 board I have has never done that.

calm elbow
#

I am able to reproduce "Invalid pins". I think this might be a problem of a second SERCOM not being available for board.SPI() and board.I2C.

#

Here is a very simple reproducer:
after a hard reset, with no code.py:

>>> import board
>>> i = board.SPI()
>>> s = board.I2C()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid pins
ο»Ώ```
#

same thing happens if I reverse the two lines

stark reef
#

@calm elbow Give #10402 a try.

calm elbow
#

I will, though I'm not sure this is a deinit problem, because nothing is inited after a hard reset.

calm elbow
#

doesn't mean this isn't still a bug πŸ™‚

calm elbow
#

@night gazelle ok, I think this is the issue re "Invalid pins":
The SAME51J chips have 6 SERCOMs, unlike the 8 for SAME54.

#

So SERCOM 6,7,8 are not available.

#

For pins PB30/31, which you are using for I2C, only SERCOM5 is available:

image.png
#

SERCOM7 is not available on this chip

#

For pins PB03, PB02, and PB00, which you are using for board.SPI(), only SERCOM5 is available:

night gazelle
calm elbow
#

so once either board.I2C() or board.SPI() is instantiated, you can't instantiate the other. In this case, "Invalid pins" means "these pins aren't available"

#

but SPI must also be on SERCOM5, and they can't both use SERCOM5 simultaneously

#

so board.SPI() works, using SERCOM5, and board.I2C() works, using SERCOM5, but not at the same time

#

there are plenty of SERCOMs, even after allocating all three SPI's you have listed in mpconfigboard.h, but it will require choosing some other pins, and maybe some trickier trace routing.

#

so you'll have to make sure that all three SPI's, and I2C, and maybe a pair of pins for UART all can use separate SERCOM's. This is the trickiness of not having a full crossbar.

night gazelle
#

What do you mean "full crossbar"?

calm elbow
#

any pin routed to any peripheral. The Espressif chips and Nordic chips tend to allow that (it's not completely any to any, but in general most GPIOs can go to most periphals

#

crossbar in the sense of X and Y grid (pins vs peripheral connections) and you can turn on arbitrary intersections

night gazelle
#

I'm wondering if dropping in a SAME54 would be worth it?

calm elbow
#

crossbar is an old telephony term, originally

#

I think you can work out the pin assignments with a '51, but it's a bit of musical chairs

#

Limor (Ladyada) has spent considerable time in the past choosing pins for various SAMD boards to maximize the number of availabe SERCOM's

#

it's not hard, just tedious

#

so for instance if you want to leave PB30/PB31 for I2C, then choose non-SERCOM5 for everything else

#

or maybe choose PB00,01,03 for SPI on SERCOM5, and then find a free SERCOM for I2C based on the other unused pins

#

etc,

#

and which pads you can use for which pin functions is also tricky

night gazelle
#

At the beginning of this project I made a SERCOM allocation file.
Unfortunately, originally I included SERCOM 6&7.

But I updated it once I found out.
Attached is the current allocation.

πŸ“Ž SERCOM_Allocations.xlsx
calm elbow
#

looks good, but there is no "general SPI" SERCOM listed in the chart, though you could use the DEBUG SERCOM

#

what is the LCD? I don't see it on the board. Is that going to be added?

night gazelle
#

I think that's a fair trade-off.

#

The LCD is on the ruler that the dev board connects to

calm elbow
#

the ST7789 is just for testing right? So practically speaking, you wouldn't be using that and the LCD at the same time. But still, having a spare SERCOM for other SPI or a second I2C bus or a UART would be good.

#

I don't see any unconnected pins so everything is available: the shuffling can be done in software and board silk. Just moving board.SPI() to the debug pins would be fine, I think, and then you don't need to re-route

#

though it would conflict with the silk "DEBUG RX" and "DEBUG TX"

#

i am getting into product mgmt here -- that's your purview

night gazelle
#

The ST7789 is the LCD on the ruler base board

#

I think since we also have a USB serial port, the Debug RX & TX wouldn't be used much, so they can share a SERCOM with a general purpose SPI port.

#

I have a different question for you.
I have a working audio output demo working on the M4 Feather.
When I try to run it on my board, the audio output is heavily attenuated to the point of being virtually silent.

On my board I have the audio outputting on the same pin as the known working M4 Feather demo.

Is there somewhere in the build files that I need to allocate audio output?

The code 2.py name is an artifact of MS Teams. On the MCU it's called code.py

πŸ“Ž code_2.py
calm elbow
night gazelle
#

That was it, thanks!

night gazelle
#

Something weird I see with the dev board (with 8MB QSPI flash) connected to my Windows machine.
CIRCUITPY drive has total 493kB space (instead of about 8MB). I also get a G: drive but it has no storage, like Windows thinks it's a CD drive or something

PXL_20250617_193821465.jpg
night gazelle
#

Interestingly, when I double click the reset button to go into bootloader mode, I can see the full storage.

PXL_20250617_201254677.jpg
calm elbow
#

The CPYNANOBOOT drive is a fake -- it doesn't represent real storage. It is writing to the internal flash on the SAME51, not to external flash. The size does not correspond to the size of internal flash either

#

The small CIRCUITPY is because of that temporary change we made a long time ago: INTERNAL_FLASH_FILESYSTEM = 1. Lemme change that and make a new build and try it.

calm elbow
#

@night gazelle I just pushed a change to mpconfigboard.mk that switches back to the external flash chip filesystem. Here's a build. I tested it a little bit and it seems to work. Copy off any files in your current CIRCUITPY that you want, because they will not be present in the new filesystem.

πŸ“Ž firmware.uf2
night gazelle
#

After I flash that firmware from bootloader mode, I get 4 yellow flashes and I don't get a CIRCUITPY drive.
Mu editor doesn't find the device either.
Device Manager shows the device and I can connect through TeraTerm, but nothing appears in the terminal.
SentinelOne is not blocking the device

#

Wait the CIRCUITPY drive appears about 3 minutes after either having the firmware flashed, or being reset.
There is no terminal output of "Hello World"

#

About every 20 seconds I see a single green flash from the NeoPixel, but no terminal output

#

If I try to save code.py (either in Mu or Notepad++) I get an error about permissions and insufficient disk space

calm elbow
night gazelle
#

Can you please send the firmware again, just in case there was an issue sending it?

calm elbow
#

does my board match yours including the flash chip on-board?

#

someone else mentioned this "3 minutes later" problem, but was not willing to work with us further to diagnose it. Do you have a non-Windows machine to try it on?

night gazelle
#

Which flash chip do you have? I have the SST26VF064B

#

I have a non Windows machine at home, could test this afternoon

calm elbow
#

I downloaded the .uf2 from above and re-loaded it, and it's working fine πŸ˜• so it should be ok. Try it again, maybe make sure there is not another firmware.uf2 in your download folder. This might be firmware (1).uf2, etc.

#

my flash chip says "26F064B" without the "V"

night gazelle
#

I have to send the file to myself over Teams and then use it. I'm wondering if Teams is corrupting it.
Can you please email me the firmware?

calm elbow
#

sure

#

...sent

#

can you see google drive links or are those blocked too?

night gazelle
calm elbow
#

ok, next time, we'll give it a try πŸ™‚

night gazelle
#

Looks like the result is the same after flashing. Trying rebooting my laptop again before flashing again to see if that helps.
I have had a lot of problems with this laptop...

#

Same result unfortunately

calm elbow
night gazelle
#

I don't have anything other than work Windows laptop at work. I can test on Ubuntu this afternoon.
Currently they have me moving cubicles, so that's going to eat up a few hours πŸ™„

night gazelle
#

At home now and it detects the board immediately, terminal works and I can program it.

#

Looks like I'm WFH for the rest of the week!

night gazelle
#

@calm elbow Working on some audio output examples. I have no problems playing WAV files. Now I'm trying to generate a variable tone for a digital "Theremin". I have followed the Play a Tone example here
https://learn.adafruit.com/circuitpython-essentials/circuitpython-audio-out
But it seems it generates the sine wave array before the loop. Im trying to change the frequency during the loop.

Is there a different library I should be using? I've been looking around but have come up short

CircuitPython Essentials

The next step in learning CircuitPython.

calm elbow
#

pitch bend, multiple voices, different waveforms, etc.

night gazelle
#

@calm elbow with the CircuitPython Nano board you have, does the BLE blue light blink when advertising or connected?

calm elbow
#

@night gazelle I am getting RuntimeError: No adapter available when trying to run a ble example. Could you upload a test program you're using?

night gazelle
#

@calm elbow I just emailed it to you

calm elbow
#

@night gazelle And I have just emailed you a build with synthio turned on (and also other things like gifio, ulab, qrio). Basically most everything is turned on.

#

@night gazelle No blue LED. D1, the red LED is very dim

#

also getting Data received: None from the test program every time.

calm elbow
#

@Ross I modified your BLE program to be just a simple terminal interface to the RNBD45, and couldn't get it to work then either. I also checked the pins for BLE_TX, BLE_RX, and BLE_CLR, and they look ok according to the schematic. I emailed you the program. But your program looks OK too. I tried sending just \r instead of \r\n. didnt' help.

#

@night gazelle

night gazelle
#

Can I get you to do a continuity test between BLE_CLR pin and GND?

calm elbow
#

@ross I only see a few ohms between.

#

@night gazelle

#

analog meter was a little clearer. I got some strange increasing results in one direction with a DVM, as if I were charging a capacitor

night gazelle
#

Super weird, trying to figure out how that happened.

My boards BLE was working last week, now there's a short between BLE_CLR & GND. Visual inspection doesn't show anything suspicious

calm elbow
#

I did solder the pins, after noticing that the header was coming out when I unplugged from a breadboard

#

measures 0v when plugged in (and no program running), despite the pullup. I'll try pulling the pin high from CircuitPython

night gazelle
#

I was toggling the BLE_CLR pin and the Saleae showed 0V

calm elbow
#

same here. Went from almost 0mV to maybe 150mV, but no higher

#

I'm just measuring with a meter

#

some design rule violation?

night gazelle
#

Maybe, but the BLE module on my board was working as expected last week

calm elbow
#

trying 3.3V pullup with various resistance values. at 220 ohms, only 0.5V at BLE_CLR

#

i am seeing some double-wide solder blobiness on the module near R13 (the BLE_CLR pullup). I'll try to get a photo.

#

upper left from the 01C resistor (which is R13)

2025-06-23-204307.jpg
#

better focus

#

that is near the pin end of D13

night gazelle
#

The 2 pins where the arrow points are both GND. Still, it's poor soldering

calm elbow
#

was there a stencil, or is this hand assembled?

#

or both

#

is yours similar?

night gazelle
#

Both prototypes were hand assembled

calm elbow
#

where does the via go? is the trace above the 0 on the resistor the BLE CLR_pin?

#

(if so, not sure why there's a via)

night gazelle
# calm elbow is yours similar?

Mines not quite so bad, but not great. I tried getting a soldering iron tip in there after adding some flux, but it's quite challenging.
I think maybe the large GND pad under the BLE module is pulling away most of the heat

calm elbow
#

i only have the schematic, not the board files

night gazelle
#

BLE_CLR trace highlighted

PXL_20250624_010513712.jpg
calm elbow
#

so that trace is on another layer, and is not dangerously close to the rectangular ground pad, despite the appearance, I guess

night gazelle
#

I just tried exporting the PCB file in Altium but it blacks out most of the board

PXL_20250624_010837307.jpg
night gazelle
calm elbow
#

The SAME pins look fine on mine

night gazelle
#

I sent Bob Martin a message asking if had heard of the modules BLE_CLR line getting pulled to GND.
Expecting a reply tomorrow

calm elbow
#

@night gazelle I did a little light scraping with a Dupont pin in the area marked here, especially between the BLE_CLR trace above the 0 and the solder blob, and now I don't see a short to ground: I see a few kohms. And, when powered up, I see 3.3V on BLE_CLR. The test programs are still not working, but this is some kind of improvement.

night gazelle
night gazelle
#

@calm elbow I was going to get Bob Martin to help me walk through the process, as I didn't wake up risk bricking the BLE module.

He's setting up for Sensors Converge trade show and won't be able to help until Friday.

I'm going to work on other things in the meantime

night gazelle
#

@calm elbow I am trying to use the PWM output with Variable Frequency https://learn.adafruit.com/circuitpython-essentials/circuitpython-pwm
On my board I have PA02 being the dedicated PWM pin. PA05 is used for the LCD display on the baseboard.

If I try to run the example code and tell it to use the pin board.DAC (PA02), I get an Invalid Pin error.
Is this something set in the CP build that can be changed to support that pin, as in the datasheet both pins support DAC output?

calm elbow
# night gazelle <@329766224093249548> I am trying to use the `PWM output with Variable Frequency...

hi - PWM uses the TC and TCC peripherals, not ADC. PA02 doesn't have access to any TC or TCC peripheral. Whether to use a TC or TCC depends on whether or not variable_frequency is True, and whether another PWMOut is already running at the same frequency. TC's are preferred for variable frequency, TCC's are preferred for fixed frequency (because they have multiple outputs). You can look in ports/atmel-amd/common-hal/pwmio/PWMOut.c if you want to see the gory details.

#

But since PA02 has no TC or TCC whatsoever, it's always going to be invalid.

#

arduino calling PWM output analogWrite() was a mistake πŸ™‚

#

analogio.AnalogOut() and analogio.AnalogIn() should both work on PA02

night gazelle
calm elbow
#

you could also use audioio and generate a tone with synthio or by computation. synthio has pitch bend

#

are you using the raw TouchIn.value for the theremin?

#

bitbanging PWMOut is not so feasible, but should not be necessary

night gazelle
#

I was going to use an APDS9960 to measure proximity distance and map that to a PWM frequency

calm elbow
#

do you already have a speaker/amp connected to PA02 on the motherboard ruler?

night gazelle
calm elbow
#

uses synthio

#

I'm sure this could be cut way back. also you could ask in #help-with-circuitpython for help with making a theremin with synthio. someone like todbot might respond

calm elbow
night gazelle
#

For now the analog out will do. I can work on more complex examples while the upcoming PCB rev is happening.
Thank you very much for your help!

night gazelle
#

@calm elbow I have an odd issue that has me stumped. The file code.py (and another file) on CIRCUITPY drive is now showing as read-only and I cant modify it.

Im using Ubuntu 24.04, opened a terminal (my username is rsatchel):
sudo chown -hR rsatchel:rsatchel /media/rsatchel/CIRCUITPY
Then when I check in Nautilus it shows me as the owner.

However, code.py still wont let me change it.

I also used:
sudo chmod +rwx /media/rsatchel/CIRCUITPY/code.py which gave the output chmod: changing permissions of '/media/rsatchel/CIRCUITPY/code.py': Read-only file system.
In Nautilus the lock symbol next to code.py disappeared, but when I tried to open the file in Gedit, it gave the message Could not open file: You do not have the permissions to open the file.

image.png image.png
calm elbow
# night gazelle <@329766224093249548> I have an odd issue that has me stumped. The file code.py...

@night gazelle This is usually because the filesystem has become partly corrupted. Copy off anything you need to copy off, and then in the REPL, type these two statements:

import storage
storage.erase_filesystem()

This is will erase and reformat CIRCUITPY. The board will reset.

The usual reason for this happening is that a flash write was interrupted somehow: often the board was reset or disconnected before the write had completed. Windows may wait several seconds before completing a write. doing an "Eject" in windows will force the writes to complete.

night gazelle
#

@calm elbow I finally have the PCB rev and have started testing.

I programmed the fuses, then the bootloader into the 1st 16kb, put bootprot back on.

I'm using the bootloader adafruit-circuitpython-same54_xplained-en_US-20250414-main-PR10249-f7e14be.uf2 (not sure if there was a newer one I should be using?)

I'm using CP build curiosity-with-synthio-et-al-2025-06-23.uf2

I was able to program our successfully several times without issue. Now I'm getting read-only messages when I try to program the board.
I'm using Ubuntu and the board is not getting blocked by SentinelOne.

Any suggestions on where to look to solve this?

calm elbow
#

in the REPL to erase and reformat CIRCUITPY

night gazelle
#

Dumb question: I'm trying to flash the latest bootloader & build to the new boards.
Is this the most recent bootloader you sent?

bootloader-microchip_circuitpython_nano-v3.16.0-19-g4365018.bin

And I believe this is the latest CP build you sent?

curiosity-with-synthio-et-al-2025-06-23.uf2

Is that correct, or am I missing the latest?

calm elbow
#

And I think that's the last uf2 I sent you, yes.

#

I found the build dir in my clone of your repo. The dates match.

night gazelle
#

The bootloader INFO_UF2.TXT matches.

After programming the bootloader, I drag & drop the uf2 and the NeoPixel turns white.
But the CIRCUITPY drive doesn't appear.
I'm using a separate Ubuntu machine to avoid the Windows problems I was having earlier

calm elbow
#

you could try that UF2 on the old board

#

this sounds like a board issue, maybe

#

if CircuitPython can't talk to the flash chip, CIRCUITPY would not appear

night gazelle
#

Do you remember if we added support for both the 32Mb and 64Mb flash chips (SST26VF032B and SST26VF064B) ?

calm elbow
#

yes, that build has

EXTERNAL_FLASH_DEVICES = "SST26VF016B,SST26VF032B,SST26VF064B"
#

are you seeing the REPL? It would go into safe mode and report that it can't see or create CIRCUITPY

night gazelle
#

I see ttyACM0 when in bootloader mode.

If I double click the reset button it disappears. So I can't get to the REPL

calm elbow
#

double-click should show the BOOT drive. single click should go to CircuitPython.

night gazelle
#

Sorry typo. Double click shows ttyACM0 and NeoPixel is green.

Single click ttyACM0 disappears.

I have tried reflashing the synthio uf2. NeoPixel goes white, but no drive appears.

Have tried power cycling with no change

calm elbow
#

ACM0 in bootloader mode is expected

#

did you try the same UF2 on the old board?

#

do you have more than one sample?

night gazelle
calm elbow
#

which one shows EX54BOOT, old or new? And does the one I sent back also say EX54BOOT?

night gazelle
#

New rev (working sample) shows E54XBOOT

Old rev (including one you sent back) shows CPYNANOBOOT

calm elbow
#

I sent you a bootloader as an attachment on 4/7/25, 18:37 eastern time. not sure if that's the same one, but it's one I built

#

i can send it again if you can't find it

night gazelle
#

Could you please resend it?

calm elbow
night gazelle
#

The new sample that currently works (with E54XBOOT), when I connect Atmel ICE and try to read signature I get this error.

What I've tried so far:
Confirmed target power (3V3). Double checked device (SAME51J20A). Disconnected all cables and firmly reseated. Restarted laptop and Atmel Studio. confirmed interface is SWD. Tried different Atmel ICE.

PXL_20250902_205229537.jpg
#

I never set the security bit previously

night gazelle
#

The 2nd sample of the new rev:
I programmed the bootloader with the file you just sent.
Programs successfully, NeoPixel turns green (enabled 16kB BOOTPROT after programming).
I drag and drop the synthio-et-al (NeoPixel turns white).

Doesn't show CIRCUITPY drive.

calm elbow
#

so it seems like either bootloader is "OK", in the sense that either one works.

#
  1. are you familiar with using Arduino? Could you try a simple Blink program? The bootloader should be able to act as an Arduino bootloader (speed change to 1200 will switch to bossac upload mode, etc.)
#
  1. is there any difference in the Rev on the SAME51J20A?
#
  1. and you see CPYNANOBOOT on the second sample after double clicking?
#

I have seen that kind of error before with a J-Link (about the security bit). It is specious, but I think it was because of a bad connection.

#
  1. on the second board, do you see ttyACM0 after single-clicking reset? (probably not)
night gazelle
night gazelle
calm elbow
#

can you get blink to work on one of the old boards?

#

see if INFO_UF2.TXT is identical on the old and new board

#

sorry, re the chip rev, I meant is the SAMD51E chip itself the same rev?

#

can you send me the new schematic?

night gazelle
calm elbow
#

i thought it's on the chip legend, maybe via the date code. I don't think this is the issue, it's just that I think the SAMx51 had a rev recently

#

I am just trying to figure out what's different on this board, since the old board works

night gazelle
#

What's the makefile difference between the E54 and E51?

Taking to Bob Martin trying to work through this

calm elbow
#

but where are we using SAME54 builds?

#

My understanding is that between your old and new boards, the components are the same. The diff is I2C pinout, and as you said, some new grounds

night gazelle
#

I managed to get new PCB rev build #1 (the one that had E54 bootloader) to take the E51 bootloader. I had to keep resetting the board, so it was likely stuck in a tight loop.
That board still works as expected.

Wondering if I should add a reset line to the SWD connector?

calm elbow
#

yes, I think I now remember that lack of reset can cause the security bit false alarm. Sometimes I have to wire up SWD by hand, and a missing reset can do that. I was not aware it was missing on your board.

night gazelle
#

Got my hands on a USB protocol analyzer. Going to debug with it tomorrow with Bob Martin to figure out if the CP actually gets programmed

calm elbow
#

if, after you upload the UF2, you stay in the BOOT drive, and you see the name of the UF2 file in the BOOT drive, then that means the UF2 flash has failed.

You could use SWD to dump the internal flash and see what's in it. use strings and see if you find various CircuitPython things.

#

actually I did not get the schematics, will reply to your email

calm elbow
#

see email

calm elbow
#

i just went over the schematic you sent.

night gazelle
calm elbow
#

which board did you choose? Arduino 18 is not PA18, etc. They are remapped

night gazelle
#

I used
#define LED1 PIN_PA23
etc

I used Adafruit feather M4 CAN

calm elbow
#

that will remap a lot of the pins, yes

#

is a table of pin numbers. So line 38 (first line in table) is Arduino pin 0, which maps to PB17, etc.

#

i'll see if there is any generic board...

#

PIN_PA23 is just 23, and is defined in a bootloader file, and so will use the arduino 23 mapping ,which maps to PB22 (line 80 in that file link)

#

there is no generic board def

#

on the curiosity board, looks like PB23 is labelled D13 (which Arduino is completely unaware of), and PORTB, 23 is on line 81, which is arduino pin 24. So you can use 24 for the pin number for the Blink LED pin.

#

I don't see a better guide than that, but I would hope there is. We don't have one our selves

#

i would also look for something really easy like the flash chip installed rotated wrong or similar

night gazelle
# calm elbow i would also look for something really easy like the flash chip installed rotate...

I suspect it's a hand assembly issue. I'll get the tech to build another to get a consensus.

In the meantime, I'm trying to solve another issue. The (working) boards (both new rev and prev rev) don't autodetect on Windows. I thought it might be a SentinelOne issue, but I tested it with my home windows machine last night, and it doesn't detect.
Bootloader mode detects in Windows but when I press reset I get nothing.
The weird thing is the prev rev boards used to work in Windows a while ago, then just stopped.

Have you seen anything like this before?

calm elbow
#

do you see a COMnn port appear, even if the drive doesn't appear?

#

by "detect" do you mean CIRCUITPY appears?

night gazelle
#

I get a COM port in bootloader mode and a different COM port when I reset the board

night gazelle
calm elbow
#

if CircuitPython is loaded, but there's some problem with the filesystem, that makes sense. If you get a COM port after single-clicking, that should be CircuitPython coming up. Connect to that port with a serial program like Tera Term, see if you can talk to the REPL, and see whether the board prints some error info after a reset or a ctrl-D.

#

try

import storage
storage.erase_filesystem()

to erase and reformat the filesystem

night gazelle
#

When I open teraterm to the COM port shown on device manager, I just get a blank terminal.
Ctrl-C and pressing reset button does nothing.
Tested on both work Windows machine and personal Windows machine

calm elbow
#

did you try reloading the synthio UF2 fresh? After you try the reload, the BOOT drive should disappear. If it doesn't, then the upload was unsuccessful.

#

you don't have a non-Windows machine to try on, is that right? (Linux or Mac)

#

I am going to take a walk to get groceries but will have my phone for q's

night gazelle
#

I wonder if there's some Windows driver I need to install for the flash chip?

calm elbow
#

I have multiple Windows machines, 10 and 11, and I keep them up to date. I have not seen something like this recently. But I don't use them daily with CircuitPython.

night gazelle
calm elbow
#

that makes sense. Since it did not stay with the BOOT drive visible after uploading the UF2, it thinks the upload was successful. If an upload was unsuccessful the BOOT drive would not disappear, and you would see the name of the "bad" UF2 file in the BOOT drive

#

are the windows machines running an antivirus program besides Windows Defender or are they running Samsung Magician?

#

the neopixel turning white also makes sense, but it sounds like it's having trouble starting

#

since it works on Ubuntu, we can narrow down the problem to Windows, instead of the board

night gazelle
#

I have tried uploading the build on Windows and Ubuntu 22.04. Same result - CIRCUITPY doesnt appear for this board, the other one works as expected - I just uploaded the UF2 onto the working one.
Yesterday we replaced the flash chip (co change) and then the MCU (also no change)>
USB protocol analyzer shows traffic when in BOOT drive and nothing after pressing reset button.

We have SentinelOne, which shows when devices are blocked. Its not appearing in Sentinel One's blocked devices list.

calm elbow
#

but some antivirus programs don't block the drive, but still interfere with the drive in various ways

night gazelle
#

So theres 2 problems Im trying to solve:

  1. Neither new rev board CIRCUITPY drive appears in Windows.
  2. After uploading UF2 to only 1 board, it doesnt boot up with CP
calm elbow
#

so you have two new boards, one works, one doesn't. The one that doesn't work had both MCU and flash chip replaced

night gazelle
calm elbow
#

i think these problems are unrelated. I would keep testing with only the "good" board that works on Ubuntu. There is something wonky about the other board, but I don't really know what the problem is. Were the board traces vetted by some QA process?

#

do the old boards show CIRCUITPY on Windows?

night gazelle
#

Allegedly the board traces were vetted. I have to wonder if there is some issue there though

calm elbow
#

i guess I would do some voltage comparisons of pins between the two boards, especially around the flash chips, and/or hook up a protocol analyzer to the flash chip

night gazelle
#

Interestingly the board that works on Ubuntu (has a blink program for onboard LED) when connected to Windows machine blinks about twice then stops.
On Ubuntu machine it blinks forever

calm elbow
#

is that the new good board?

#

or an old board?

night gazelle
#

New good board.

Does the same thing on my old personal Windows machine and work Windows machine - blinks twice then stops

calm elbow
#

is that an Arduino Blink or a CircuitPython blink

night gazelle
#

CP

#

I gotta run to an appt. Will be back in about an hour

calm elbow
#

if you open Device Manager and plug in the new good board, would be itneresting to see whether devices appear and disappear

night gazelle
#

New good board (under Windows):
BOOT drive shows as COM16
Press Reset button, COM 16 disappears, COM7 appears.

Disconnect and plug back in (not in BOOT), COM7 appears again

night gazelle
#

On my personal Windows laptop it is COM5.

On both work and personal Windows laptops I see this under Events in the COM port properties.

image.png
#

On my personal Windows machine, I unplugged it, uninstalled the driver and plugged it back in. Now I get this:

image.png
#

It still wants further installation, but recognizes as CircuitPython CDC

image.png
#

The good new board is running a blink sketch. I can now see the LED blinking continuously (doesnt hang like it used to). However when I open Mu and change the blink rate it says I dont have permissions.

image.png
#

I couldnt connect to it on the Windows machine, but I plugged it into the Ubuntu machine and erased the filesystem.
Plugged it back into personal Windows machine and got this.

image.png
#

At the time Update Driver was greyed out. Now it says its up to date and working.
opened Mu, changed the blink rate of the program and got the permissions messgae again.
Opened the serial terminal in Mu and entered the REPL.

import storage
storage.erase_filesystem()
#

Still getting permissions message when I try to save code πŸ™

night gazelle
#

I tried deleting the driver again. When I plugged it back in, I got CircuitPython CDC for a little while, as it looked for a driver.
Eventually it became COM5.
It was detected by Mu and could open Mu's serial terminal and see print statements executing.

When I tried to change the blink rate and save the code, I got the permissions message and the LED stopped blinking.

Its progress at least!

image.png
calm elbow
#

This certainly seems like something that is interfering with CIRCUITPY. You mentioned you are seeing this on your home computer too. I wonder if CIRCUITPY is getting corrupted at work due to some utility or security program. Maybe try the home computer, but do the storage.erase_filesystem() at home and then see if the problem persists.

night gazelle
calm elbow
#

if nothing rings a bell, could you take a screenshot or copy/paste the list of installed apps? You could send it to me privately if you'd prefer.

#

is the personal laptop Windows 11? make sure you're either ejecting the drive before pressing reset, or at least waiting 10-15 seconds after a file write.

#

also look in Device Manager under Drives (or whatever it's called), and see who's the author of the driver for the USB drive. It should be Microsoft. If it's Western Digital or Acronis or some other mfr, that's a tell.

night gazelle
#

I jus sent the installed apps on my personal Windows 10 laptop as a DM.

Heres the properties of the device under Device Manager:

Under Events it says it needs further installation, but if I click update Driver under Driver tab and select Search Automatically For Drivers, it says the best drivers are already installed. If I then click Search for updated drivers on Windows Update, then it says Im up to date.

image.png image.png image.png image.png image.png image.png
calm elbow
#

I think it may well be Cura, as you sent me.

#

uinstall it or turn off "USB printing". It spams all available COM ports, trying to see if they are 3D rinters

night gazelle
#

The whole time I can see the blink program running, and can see the Serial window outputting the print statements I added to the blink program.
I cna enter the REPL and did CTRL-C and did

storage.erase_filesystem()
#

Uninstalled Cura, will reboot now

#

Rebooted, same problem

calm elbow
#

getting a screen shot for you...

#

@night gazelle look at the drive for CIRCUITPY and see what driver it is using

image.png
night gazelle
#

Ive got 2 drives showing, even though only 1 plugged in

image.png
#

First one:

image.png
#

2nd one:

image.png
calm elbow
#

that's OK, the second drive is for automounting an Sd card

#

but the driver version looks OK. If it were Western Digital, etc. I would be suspicious

#

any other Windows machines at home that you might try?

#

could also try rebooting into Safe Mode to prevent anything from loading. I didn't see anything else highly worrisome, but maybe the Atmel drivers:

image.png
night gazelle
#

To get the CIRCUITPY drive to appear, I have to uninstall the driver under COM ports. When I plug it back in I get this:

I have it programmed with a blink sketch and see it start to blink a few times then each time stop for a minute or so.

After it does that 3-4 times the CDC control properties un-greys out (makes it able to click the Update and Uninstall Driver buttons, and the LED starts blinking constantly.

Under COM ports it also changes from CircuitPython CDC control to COM5.
So it seems it reinstalls the driver.

I cna then see the CIRCUITPY drive and its contents.

Mu editor then sees the device and I can open the Serial Terminal. But when I modify the program and try to save I get the permissions error.

image.png image.png image.png
#

Remoiving Atmel drivers now

calm elbow
#

the board is identifying with two different USB VID/PIDs. The bootloader PID is different from the CircuitPython PID, so it's a different device, from Windows' point of view

#

and you still get the permissions error after doing storage.erase_filesystem()?

#

the stopping business is totally weird

#

is there a backup or indexing utility running on Windows?

night gazelle
#

No backup, but there is google drive?

#

Removed the Atmel drivers. rebotting

#

Rebooting

calm elbow
#

is there a google drive app installed that makes it look like a drive?

night gazelle
calm elbow
#

can you disable that temporarily. I don't think that's an issue but you never know.

#

i was wondering if a family member has a more vanilla Windows machine at home you could try

night gazelle
#

I just uninstalled google drive.
My wife has a work Windows laptop that I can try tonight.

This one Im currently using is the most vanilla Windows machine I have

#

Same result πŸ™

night gazelle
#

Just plugged the board into my work Windows laptop. It does the same thing (running the blink sketch) where it blinks once or twice, waits a 30-60 sec, does it again. It does this about 4 times before finally it blinks continuously.

Then when I open Mu it does the blink thing again (blinks once or twice before stopping for 30-60 sec) about 5-6 times before finally blinking continuously. At that point I can open the Mu Serial window.
Any changes to the code get the permissions popup - "Could not save file (disk problem) Error saving file to disk. Ensure you have permission to write the file and sufficient disk space"

I can access the REPL and do CTRL-C

# 
storage.erase_filesystem()
#

I get this, even after the CIRCUITPY drive appears

PXL_20250905_193223190.jpg
night gazelle
#

Interestingly, after the blinking thing settles and starts running the blink program continuously, I can read the code from the board.
I just cant write to it πŸ€·β€β™‚οΈ

night gazelle
#

Just tried it on my wifes Windows laptop.
It was the same result where it would start blinking then stop multiple times with 30-60 sec in between each attempt. Looking at device manager it seems like it was loading the driver (yellow ! mark beside CircuitPython, which later disappears and drives is assigned a COM port number.

Was able to read code.py from the board.

Tried to write to the board and got permissions error

night gazelle
#

Works on Mac without any problems.
Need to find another Windows machine

calm elbow
#

do you have any Adafruit boards (SAMD21 or SAMD51, say) that you could try on these Windows machines? I don't see why it would be these boards in particular, but 🀷

night gazelle
#

I have a Feather M4 CAN that does the same thing on my work Windows laptop.
If I just connect it, nothing shows up. If I double click the reset button I see the FTHCANBOOT drive

PXL_20250908_162407706.jpg
#

Also I just Fedexed to you the same Microchip Curiosity dev board that you recently shipped back to me.
For these purposes, it should effectively be the same as the new rev.
It also has the same failure to detect issues the new rev has.
I'm hoping it might help in figuring out this issue.

night gazelle
#

I'll test the Feather M4 CAN on my home windows machine tonight

calm elbow
night gazelle
#

I just tried both the mchp CircuitPython board and an Adafruit Feather M4 CAN on another non-microchip vanilla Windows machine.

In Windows Explorer, it detects the BOOT drive (on both mchp and Adafruit boards), but does NOT detect the CIRCUITPY drive of either board.

In Device Manager I get a COM port but no drive on both mchp and Adafruit boards when in normal CIRCUITPY mode.
But I do get a drive and COM port when in BOOT mode for both boards (tested separately).

I really think this is a Windows issue as the old rev (that I just sent to you) used to work in Windows earlier this year, and stopped working.
At the time I had many other problems to solve, so put this problem on the back burner and worked in Linux instead.

calm elbow
#

i have not had trouble with SAMD CIRCUITPY on my own Windows machines, so this is pretty puzzling, especially if it's your family machine without Sentinel One.

calm elbow
#

I got the FedEx package and hope to work on the board def later today.

calm elbow
#

I updated your PR, bringing it up to date with circuitpython main, and also updated the board definition, turning on more modules (since there's a lot of flash available), and redoing the pin definitions a bit. See https://github.com/adafruit/circuitpython/pull/10287/commits/06f7192cba388a3da683387a959c8bc1a73f2e82#diff-8812454f6d0acc8ab72fead409681a9453c3c9924234590e65d8b82550e7c846. I used the new schematic. I did not see a swap of the BLE UART pins. I renamed NEOPIX to NEOPIXEL, which is more standard.
For the standard SPI bus board.SPI(), I didn't change the pins. I did see that the SPARE pins now have more conventional names and switched to those. Aliases for the same pin were grouped together, so a few pin names moved around. The "primary" name is listed first (e.g. LED is preferred over D13).

There is a build here: https://github.com/adafruit/circuitpython/actions/runs/17600207769 (direct download: https://github.com/adafruit/circuitpython/actions/runs/17600207769/artifacts/3970649980) that you could try on the new board.

night gazelle
#

We are about to get the new boards made, so once they arrive I can test.

#

Have you had a chance to test the board I sent on your Windows machines?

calm elbow
#

are you making a production run or a larger sample run?

calm elbow
#

Tested the board you sent me with the latest build linked above. There was a CircuitPython Blink program already there as a code.py. It showed up as CIRCUITPY and has been running for ten minutes or so. CircuitPy is still visible.
on your home machines: is Malwarebytes installed on both? How about the Cisco software?

night gazelle
#

Malwarebytes on home machine.

Cisco VPN on work machine. Interesting, it used to work on my work machine then just stopped a few months back

#

I'll take my home machine in today and test it with Malwarebytes removed

calm elbow
#

was malwarebytes on the other (not yours) machine at your house? Or maybe that wasn't a good test (sounds like you might have been trying to see CIRCUITPY but with Arduino Blink, if I remember)

night gazelle
#

My personal home laptop has Malwarebytes.
The other Windows machine at home was my wife's work computer (Arizona State University laptop).

I had a CircuitPython blink program running at the time

calm elbow
#

I tested on my Windows 11 Pro machine, which is completely up to date as of this morning. It has quite a bit of software installed, but not extra anti-virus or malware, utility or backup programs

night gazelle
#

After removing Malwarebytes at home, I brought my old Thinkpad T430 into the office.

It was slow to detect it, but it detects!

Currently doing happy dance! πŸ•Ί

image.png
#

The thing that threw me off was work machine and home machine behaving same. I stupidly thought the root cause was the same. Lesson learned.

calm elbow
#

is this the free malwarebytes, or the paid version?

#

i will try to duplicate this

#

maybe there is a drive exclusion option for malwarebytes

night gazelle
calm elbow
#

I installed the trial version of Malwarebytes (which has the real-time scanning, etc.), but did not encounter an issue with CIRCUITPY, so that's mysterious

night gazelle
#

Interesting thing I just observed with the board that previously would show the BOOT drive but not CIRCUITPY.

I had suspected that the problem may have been caused by a lack of reset line on the SWD connector. So I soldered in a bodge wire for the reset line and replaced the MCU (as it seemed to be borked).

Flashed the bootloader, then dragged and dropped CP onto it. I now periodically see the green flash (Yay!)

Now in Ubuntu I can see the BOOT drive. But instead of the CIRCUITPY drive I instead see "4.2MB Volume".

I can open the REPL and write code at the ">>>" prompt to toggle the LED.

I suspect I also need t replace the 4MB flash chip as well.

Just wondering if you have encountered this before?

night gazelle
#

It gives me a boot_out.txt but nothing else

PXL_20250911_222352235.jpg
night gazelle
#

I replaced the flash chip then just to be sure I reflashed the bootloader, then dragged and dropped CP on it.

That did the trick.

So it seems the lack of reset line on the SWD connector borked both the MCU & flash chips.

calm elbow
#

I'm not sure there was anything wrong with either chip, but I can't use my J-Link well on SAMD chips without a reset line.

#

the SAMD51 has an internal pullup on the reset line, I thought

#

The "4.2MB Volume" might have been because the CIRCUITPY drive was corrupted in some way. We have seen that on Windows before.

#

are the voltages on the chips ok?

night gazelle
#

All voltages on chips 3.3V

#

Tomorrow I will test out the new build

calm elbow
#

you mentioned the BLE TX/RX were swapped, but I didn't see that between the old pin definition and new schematic. Or did you bodge-swap them and that was already included in the pin def?

#

i didn't look at the old schematic

night gazelle
#

I bodge swapped them on the PCB rev you have.
The PCB rev I have they work without bodge wires.
The interface with the BLE module is UART

calm elbow
#

got it, thanks

#

good night, talk to you tomw!

#

eastern time here

calm elbow
#

@night gazelle I think I will merge the current Curiosity board def into main so it can get into 10.0.0 final. We don't have to include it in circuitpython.org yet. Do you know of any needed fixes? Or would you rather wait? It's obviously not secret, but it's not announced either, I assume.

calm elbow
#

OK, not the same, 3 years old

night gazelle
#

The final rev boards arrive next week and I can do final testing.

One change that's needed is the "Nano" needs to be dropped from the name, so that it's "Microchip Curiosity CircuitPython"

calm elbow
#

Thanks. We will be doing 10.0.0 rc.0 really soon. It can go in a bit later, then. We'll probably have some more releases in quick succession as bugs are found before and after 10.0.0 final

calm elbow
#

I pushed a commit to drop the "Nano"

night gazelle
#

Awesome, thank you!

calm elbow
#

Hi Ross, I saw your notes about the PDM micproblem. Is the mic connected to the board right now?

#

I am looking for the schematic for the latest board version but can't seem to find it.

night gazelle
#

Hi Dan, I just emailed you the latest schematics.

calm elbow
#

Thanks. I don't see anything immediate. If you take the board off the ruler motherboard, does it make any difference?

#

i don't see any reason why the PDM mic should make any difference, unless a pin got fried while connecting.

night gazelle
#

I wasn't using the ruler baseboard. Just had the PDM connected to DEBUG_TX (instead of TX as per the first example in the guide) and D9.

calm elbow
#

if you disconnect the PDM breakout, does the board recover and work again?

night gazelle
#

No, that was the first thing I tried 😒

calm elbow
#

I am thinking that you are in a crashing boot loop. Does a COM port appear even if CIRCUITPY does not?

#

I also built you a special version of the Curiosity UF2 that will erase the filesystem on startup. So load this and run once, and then re-load regular CircuitPython

night gazelle
calm elbow
#

it's not good it was crashing like that. If you have the crashing program, you could send it to me here or in an issue.

#

a hard crash is a bug, from our point of view