efabless / caravel_board Goto Github PK

I see that there are numbers in the corners that line up on both PCBs. Call this out in the documentation.

currently path the usb device is hardcoded in https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/Makefile#L5 which seems to use a path specific to a macosx installation.

On Linux based operating system, the path is likely to be different (/dev/ttyACM0, /dev/ttyUSB0) so something that detect the nucleo board is probably desirable:

(env) nucleo 👹 mpremote connect list
/dev/ttyACM0 066AFF495087534867055928 0483:374b STMicroelectronics STM32 STLink
/dev/ttyS0 None 0000:0000 None None

It seems that there are three possible USB/UART connection on the nucleo board + hat combo:

• nucleo's CN1
• nucleo's CN13
• hat's J1
• hat's J4

It would be nice if each port had some documentation about what it can be used for.

Add support for 5V to Caravel all supplies to support GF180. The priority is Caravel Development Board followed by the Hat.

The design should allow the user to switch between 1.8/3.3V and 5V so that the same board can be used for either SKY130 or GF180.

I have received chips from MPW2 run. I wanted to know the orientation for bonding the chips onto the white caravel board. Pg 27 on [caravel datasheet] does have the wiring diagram. But it just says view from top and in absence of any identification mark like notch, is tough to distinguish say between A1 and F10.

@msaligane

JP6 and JP7 on Nucleo board bend the pins on the first breakout board attached. We had to use another set of headers to increase the distance between Nucleo board and Caravel Nucleo Hat.

I'm trying to order
https://github.com/efabless/caravel_board/tree/main/hardware/caravel-dev-v5-M.2
using
https://github.com/pcbway/PCBWay-Plug-in-for-Kicad

"with the current files, Anson can only exported the centroid file, but imcomplete BOM file, because when you design the file in Kicard, you did not upload the component part number, so we cannot quote, attached is the file exported, we need you to provide each part number.
https://member.pcbway.com/Message/MessageDetail?ParentId=3087836
(likely private, for my reference.)

I did not see a part number for the connector. That is the only thing I checked.

the gpio_config_builder.py script should dump a c file that has the n_bits set

This currently break integration with currently activated venv or conda environment:

$ python3 -m venv env
$ source env/bin/activate
$ python -m pip install mpremote
$ cd firmware_vex/nucleo/
$ make run
mpremote connect /dev/cu.usbmodem34203 exec "import machine; machine.reset()"
/bin/sh: 1: mpremote: not found

If you remove the line at https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/Makefile#L2 it works as expected (mpremote get resolve from the currently activated environment).

I've installed mpremote and specified the correct device. I get the following result:

mpremote connect /dev/ttyACM0
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] to exit this shell
>>> import machine
>>> machine.reset()
Traceback (most recent call last):
  File "main.py", line 1
SyntaxError: invalid syntax
MicroPython v1.19.1-616-g5987130af-dirty on 2022-11-20; NUCLEO-F746ZG with STM32F746
Type "help()" for more information.
>>>

After the reset, the User LD1 and LD2 on the nucleo board flash green and blue respectively in an alternating sequence three times.

I do not see any "green and red leds" as specified in the README.

should link to the documentation somewhere. https://www.solder.party/docs/flexypin/soldering/
You could easily miss the QR code on the package.

currently the io_config test finish by a busy loop to blink the onboard LED in order to convey the status to the user:
https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/io_config.py#L354-L362

It would be nice to rely instead on timer (if available on the nucleo port): https://docs.micropython.org/en/latest/pyboard/tutorial/timer.html?highlight=timer so that you can give control back to the main interpreter (without requiring the user to interrupt the script).

It seems that the current schematic export render text as images: https://github.com/efabless/caravel_board/blob/main/hardware/caravel_Nucleo/caravel_Nucleo.pdf making it challenging to "search" for pins and components in them.

/cc @mithro

There should be a single page where users can go that says do X, Y, and Z. The video shared doesn't show any of the setup.

https://www.youtube.com/watch?v=76hmGHJMyYs

Thje current diagnosis is simply running machine.reset():
https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/Makefile#L64
and doesn't produce any output.

(env) nucleo 🍡 make run
mpremote connect /dev/ttyACM0 exec "import machine; machine.reset()"
MicroPython v1.19.1-616-g5987130af-dirty on 2022-11-20; NUCLEO-F746ZG with STM32F746
Type "help()" for more information.
>>> 

and display a led combination that's not documented in the accompanying paper note (twe red leds, no blinking):

Dealing with the Flexy pins as a socket for the caravel breakout boards is not that great and the following are reported issues by the community:

1. Flexy pins are hard to install and solder on the Caravel main board
2. Flexy pins are fragile and get bent easily
3. Plugging in the Caravel breakout board requires a firm press that might break the flexy pins
4. Attaching the Caravel Nucleo hat board to the Nucleo all the way bends the flexy pins and they get shorted with the jumpers on the Nucleo

Another socket is required to avoid this bad experience with the upcoming boards

after reflashing with:

make F746ZG

I get the following error:

RuntimeError: name too long after reflashing

which cause the io_config bring up sequence not to start.

Getting the following error when do make run.
ayushman_ubuntu@UbuntuLTS:~/caravel_board/firmware_vex/nucleo$ make run
mpremote connect /dev/ttyACM0 exec "import machine; machine.reset()"
Traceback (most recent call last):
File "main.py", line 2, in
File "io_config.py", line 1, in
File "nucleo_api.py", line 3, in
ValueError: incompatible .mpy file
MicroPython v1.19.1-616-g5987130af-dirty on 2022-11-20; NUCLEO-F746ZG with STM32F746

Type "help()" for more information.

@msaligane

What header pins should be installed in which board?

I'd like a few of these boards (less than 10), I'm assuming I have to get them manufactured and assembled myself.
What company was used?

Is there some way to reference the previous run so I can ask for "more of that" ?

I did not have a chip made, so I'm not eligible for anything that participants are, but I was given some of the chips to experiment with.

When using the risc-v toolchain from debian:

ii  gcc-riscv64-unknown-elf                              12.1.0-7+11                                             amd64        GCC cross compiler for Risc-V processors

I get the following error when trying to compile some of the test firmware of the repo:

riscv64-unknown-elf-gcc -I/home/proppy/src/github.com/efabless/caravel_board/firmware_vex/gpio_test -I../ -I../generated/ -O0 -mabi=ilp32 -march=rv32i -D__vexriscv__ -Wl,-Bstatic,-T,../sections.lds,--strip-debug -ffreestanding -nostdlib -o gpio_test.elf ../crt0_vex.S ../isr.c gpio_test.c
../crt0_vex.S: Assembler messages:
../crt0_vex.S:59: Error: unrecognized opcode `csrw mtvec,a0', extension `zicsr' required
../crt0_vex.S:87: Error: unrecognized opcode `csrw mie,a0', extension `zicsr' required
../irq_vex.h: Assembler messages:
../irq_vex.h:31: Error: unrecognized opcode `csrw 3008,a5', extension `zicsr' required
make: *** [Makefile:30: gpio_test.elf] Error 1

It would be nice to document the toolchain requirements and guide the user thru the required setup.

The io_config.py doesn't check for GPIO#0 , it starts with GPIO#1:

*** flashing Caravel
gpio[1] >> Passed

but in the end it claims that gpio#0 is ok:
== LOW chain FAILED. Valid IO = 0 thur 14. ==

It would be nice to have the modified nucleo firmware as part of the repo so that we can know what's exposed thru the pyboard machine interface and contribute to it.

Related #63

/cc @mithro

Hello,

While trying to flash the mpw2 with any example(such as blink) read compare always fails.
I guess there is an alignment problem while writing or reading or both.
Could you please check that issue?

Best.

It seems that definitions of the function declarations in uart.h are missing in firmware_vex:

#ifndef __UART_H
#define __UART_H

#ifdef __cplusplus
extern "C" {
#endif

#define UART_EV_TX	0x1
#define UART_EV_RX	0x2

void uart_init(void);
void uart_isr(void);
void uart_sync(void);

void uart_write(char c);
char uart_read(void);
int uart_read_nonblock(void);

#ifdef __cplusplus
}
#endif

#endif

when I run Make, it will build the required gpio_config_data.c, but not from the local gpio_config_[io|def].py

https://github.com/efabless/caravel_board/blob/main/firmware_vex/matt_test/Makefile#L19

that's because the config builder includes local example python libs

I fixed this by modifying the builder to include the real files, and then copied it into the firmware directory so that it picks up the local files.

I suggest adding command line arguments to explicitly pass the configs to read, and then the makefile can call it from the original position, but use local files. The local files could also be automatically passed to the builder through make rules.

Slightly related to #65, but assuming we're using the default micropython firmware it seems that only a subset of the caravel mprj_io are exposed in the micropython HAL (despite all of them being physically connected to CN11 and CN12):
https://github.com/micropython/micropython/blob/05bb26010e4a466a82cfed179f8d8d0b406a78ca/ports/stm32/boards/NUCLEO_F746ZG/pins.csv

We should make sure that all of those are expose to the micropython environment, so that people can poke at their design directly from the micropython REPL.

there is too much room for error with the makefiles and mount points

perhaps mount points stay the same but it's very common for the serial ports to change names, especially as I have to unplug and replug the board every time I try to use it

so better to detect which is the correct port and set it automatically

Hi,

I am getting the following error when I run the IO diagnostic test given in the README.

Does anyone have any idea why this is the case and how to go about solving it
@msaligane

Thanks
Ayushman

Looking at the test being performed there seems to be multiple possible results of the GPIO characterization

Looking at https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/README.md?plain=1#L62-L66 it seems that only 3 patterns are documented: A, (B or C), (D or G)

And looking at https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/io_config.py#L354-L362 it seems that only 3 blinking modes are actually implemented with different patterns than the one documented:

The datasheet @ https://github.com/efabless/caravel_board/blob/main/docs/caravel_datasheet.pdf says;

The Caravel harness comprises a small RISC-V microprocessor based on the simple 2-cycle PicoRV32 RISC-V core implementing the RV32IMC instruction set (see http://riscv.org/).

The processor core is the PicoRV32 design (see http://github.com/cliffordwolf/picorv32). The full core description is available from the github site. The hardware implementation is the “large” variant, incorporating options IRQ, MUL, DIV, BARREL_SHIFTER, and COMPRESSED_ISA (16-bit instructions).

I'm guessing this is all wrong?

Looking at the nucleo board datasheet:
https://www.st.com/resource/en/user_manual/um1974-stm32-nucleo144-boards-mb1137-stmicroelectronics.pdf

It seems that:

In case the maximum current consumption of the STM32 Nucleo-144 board and its shield
boards exceeds 300 mA, it is mandatory to power the STM32 Nucleo-144 board with an
external power supply connected to E5V, VIN or +3.3 V.

I wonder if the data corruption #20 and flashing reliability issues #19 #16 could be related to this?

It would be nice to document the external power supply options:

• Vin
• E5V
• 3.3V thru hat

As well as some power profiling of the hat + nucleo board in action during IO configuration to assert that firmware changes don't exceed the power supply budget.