February 28, 2019 at 12:40 am #367
I am happy to announce the first experimental port of Mecrisp-Quintus to the Vega board.
It is still in an early stage, lacks direct compilation into flash memory and uses a bit-bang 9600 baud half-duplex terminal for now, but this should change soon into a full featured port of Mecrisp-Quintus.
Adventurous Forthers are welcome to join early and help with peripheral drivers and examples.
Best wishes from Germany,
PS: Many thanks to Wil Blake and Juan Mendoza for the hardware donation !February 28, 2019 at 11:45 pm #368
A few questions arose:
* For getting LPUART0 up and running, I set PORTC_PCR7 and PORTC_PCR8 to alternate 3, switched on PCC_LPUART0 with SYS OSC source (should be 48 MHz FIRC on boot, reset clock configuration not changed) and configured LPUART0_BAUD and LPUART0_CTRL. But I could not see characters coming out when writing LPUART0_DATA. Did I miss another register which needs to be set for initialisation of LPUART0 ? Bit-bang communication using PC7 and PC8 as GPIO lines is fine.
* What could happen with two 4 byte back-to-back flash writes into one aligned 8 byte location using the “program phrase” command 7, with the already programmed word set to $FFFFFFFF ? Does it slowly damage the memory due to overstress by applying the programming voltage twice; or does it simply result in less-than-specified data retention, which is okay for first testing purposes ? The reference manual specifies one write cycle is allowed into each aligned 8 byte section for primary flash.
* I know the supplied example code package using libraries is common for large chips like the RV32M1, but as a variety of languages are to be ported to RISC-V, I would greatly appreciate simple low-level examples in assembler or at least in C with direct register access, without any library usage. Please don’t be angry with me for referencing another manufacturer; but the example package for MSP430F2012 by TI given at http://www.ti.com/lit/zip/slac080 is exactly what I would wish for the Vega, at least for the basic peripherals like GPIO, clock distribution, interrupts, sleep mode, timers, UART, ADC. It would greatly simplify launching the non-C ecosystem for the new architecture.March 1, 2019 at 6:06 am #369
Any 8-byte writing, even all bytes are set to 0xFF, is a real write operation to the 8-byte a program flash block. As a result, the ‘invisible’ check bit of that program flash block will be updated. Then the next writing will fail because of the updated check bit if having no erasing. The check bit will be reset only in the erase.
All source code of the release packages for VEGAboard are available. Especially, the SDK release package includes all source code of examples that run on VEGAboard. The c code of drivers of RV32M1 are under rv32m1_sdk_riscv\devices\RV32M1\drivers folder, the registers definition and interrupt handlers are under rv32m1_sdk_riscv\devices\RV32M1. The startup code can be found under rv32m1_sdk_riscv\devices\RV32M1\gcc.
For example, the LPUART issue you met can reference the fsl_lpuart.h .c files under rv32m1_sdk_riscv\devices\RV32M1\drivers.
Suggest to install eclipse and import the examples to view the source code structure in the eclipse, then you can well understand the structure of SDK.March 5, 2019 at 1:43 am #372
Thanks for the pointers !
Mecrisp-Quintus 0.17 is released now, containing full support for RV32M1 Vega and an additional precompiled binary including disassembler, multitasker and s31.32 fixpoint math library. As my Forth core is written in pure hand-crafted assembler, everyone who wishes to conquer this interesting chip in a “bare metal” way will hopefully find a good starting point in its sources.
While searching for the correct clock configuration in GDB, I found special, undocumented read-only values in the SCG IO range. For example, 0x4002C20C is read-only (raises exception when written to) and reads as 0x013d0141. Neither 0x4002c310 nor 0x4002c314 nor 0x4002c510 are documented, too.
0x4002c200: 0x01000005 0x00010101 0x00000001 0x013d0141 0x4002c310: 0x000d1e36 0x000f1c41 0x00001e36 0x00000000 0x4002c510: 0x00000064 0x00000064
See yourself in GDB with x/326xw 0x4002C000
MatthiasMarch 6, 2019 at 11:07 am #376
Nice! Thanks for your work and enthusiasms on the VEGAboard.
You must be logged in to reply to this topic. Login here