We are working on using the UART communication on the MPW-7 bring up boards, but cannot figure out how to get the FT232H to drive UART_EN low. There are two buffers which disconnect the UART when the housekeeping SPI is in use, but when you just use screen on the ft232’s serial port, the two buffers are disabled and no UART is received. We can connect the hardware jumper J2 to receive only from the management core, but that does not feel like the intended solution. Has anyone had any luck with this?

AFAIK, you either have the jumper or you have to use any additional serial to USB converter

@jeffdi knows the solution to this, also possibly @Passant. There are hints in the

caravel_hkflash.py

file, which toggles the LED on ACBUS2 (and/or ACBUS3?). There are several not-well-documented procedures in pyftdi; in the code,

gpio = spi.get_gpio()

provides access to the low-level bit control over the FTDI chip ACBUS, and

gpio.set_direction()

,

gpio.configure()

, and

gpio.write()

control those bits. There is also in the python code a

class Led

which has a definition that looks to me like it would interfere with any attempt to control ACBUS pins other than the one driving the LED.

Yes, I went there, but that doesn’t work because in UART mode those are not available as gpio pins. You can set the gpio pins in SPI mode, but then they get reset to tristate when you try to enter UART mode

For context, “It is not possible to assign the unused pins of an UART mode to arbitrary GPIO functions.” - https://eblot.github.io/pyftdi/api/uart.html#gpio-access “Upper pins (b7..b15), on devices that have ones, cannot be driven while UART port is enabled.”

That seems like a weird restriction.

It’s in the FT232H datasheet as well

I wasn't suggesting it isn't true, it's just weird. I can't think of a reason why they would make the chip behave that way.

Yeah me neither

Thanks for the investigation. I have raised the issue internally to Efabless and we'll look at possible solutions (i.e., board redesign, maybe try the EEPROM solution). Let me know if using the HKSPI CS line (inverted) works.

The saleae trace attached has the full notes, but summary is no. The CS line does not go low during the entire time the HKSPI is being driven by the FTDI chip. It looks like you would need either an EEPROM ($0.70) or a two-interface chip (FT2232H is an option, ~$1 more than an FT232H) might be a better solution to just support simultaneous UART and SPI without all this fanciness.

Another fix we thought of is that you should be able to put a pull-up resistor on UART_EN. That way, when the UART is enabled on the FTDI and the line gets tristated, it will pull up and enable the UART. But then it is necessary to force that line to zero in the programs that run flash programming and housekeeping access. That might require some code changes (Note: I did not look at the schematic, so I may have the sense of the UART enable inverted).

That’s a great idea, I’ll look into it

Just watch out for the interactions between

gpio.set_direction()

,

gpio.write()

, and the routines defined in the

Led

class.

led.toggle()

does a

gpio.write()

when it really should be attempting to leave the state unchanged except for the one bit used for the LED.

Yeah, I got annoyed with how cluttered all those scripts were, I have a rewrite of them which has an HKSpi class to isolate the communication implementation portions that is a lot cleaner I’ll make available once I verify it works

Cool! Can we get hold of your version? I'd like to get rid of all the mess in the posted scripts as well.

All good

No, I get a log-in screen.

Cool, I’ll make that available in a better form in a bit

@gling: By the way, there are way more registers available in the housekeeping SPI than indicated by caravel_hkdebug.py. I suggest changing line 35 from

for reg in [0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12]:

to:

for reg in range(0, 0x70):

There are some unused registers in that range but it covers all of them. I think most people are unaware that all the GPIOs can be configured and driven high/low directly through the SPI interface, and the full set isn't in the repository documentation. The mapping is defined in the caravel repository

verilog/rtl/housekeeping.v

lines 344 to 483.

We discovered one issue with spi.close() not being supported on one installation of pyftdi we were using, so added a check to call terminate if close is not available. Also added the util changes as a pr to efabless/caravel_board.

I went ahead and approved the pull request.