IceCore myStorm firmware

[Folknology]

So are you getting your hang when called from the usb handler or from loop()

Loop(), I am trying to work out if it ends up in one of the handlers like HardFault..

[AndyCap]

Ok, so we had different problems with the same result.

I tried upping the sys-tick priority and that didn't work, looks like I need to look at NVIC_PriorityGroupConfig() to set things up properly.

Might leave that for another day!

[lawrie]

I am currently testing using SPI (master) from a Raspberry Pi Zero, with an SPI slave program loaded from flash:

It isn't currently working, but as this uses the same SPI pins as the flash (apart from SS) , whether it works probably depends on the state that the firmware leaves the SPI pins, so I probably ought to wait for new firmware before trying this.

[Folknology]

I tried upping the sys-tick priority and that didn't work, looks like I need to look at NVIC_PriorityGroupConfig() to set things up properly.

Might leave that for another day!

Yeah I still need to look at this (I have been putting it off), one needs to take a holistic view of all of the possible interrupts in relation to each other which is difficult when you are operating a HAL that makes all kinds of assumptions about interrupts.. For example it is easier to escalate the systick priority only to find that it overrides something like a SPI interrupt which causes that to fail or wait forever..

[AndyCap]

Yeah, I had a quick look into it and it's definitely not for a Friday afternoon!

The other way I guess is just moving it all out of the USB callback, I'm not sure how long that usb packet data hangs around for though so it may need a memcpy...

[Folknology]

The other way I guess is just moving it all out of the USB callback, I'm not sure how long that usb packet data hangs around for though so it may need a memcpy...

The thing to understand is that you should finish you process and then call :
USBD_CDC_ReceivePacket(&hUsbDeviceFS);
which will set off the next USB rx packet

You could in that process just copy into a Fifo and pick it up for spi transfer in loop() for now.

[AndyCap]

Nice, thanks for the info.

That sounds like the best solution for me for now...

[AndyCap]

Some more questions about the cdc:

We have:

#define APP_RX_DATA_SIZE  2048
#define APP_TX_DATA_SIZE  2048

The USBEndpoints have a size of 64 bytes though.

Can the STM32 usbcdc_rxcallback() ever actually have more than 64 bytes though?

[Folknology]

Can the STM32 usbcdc_rxcallback() ever actually have more than 64 bytes though?

OK I am no USB firmware expert but the packet size is limited in USB FS to 64bytes, it can be higher for USB HS.The RX and TX buffers get used for multiple endpoints so are likely segmented for that purpose (i.e. they contain sub buffers for each endpoint)

[AndyCap]

Do we have HS on the board?

HS would be 512 bytes.

There are only two endpoints as well (apart from the interrupt endpoint which will be handled elsewhere): A bulk input and output, both 64 bytes for FS.

I do know that the timing of USB data can be all over the place so wondered if the STM usb stuff will sometimes be buffering up packets and sending multiple to usbcdc_rxcallback().

Did you create those defines or are they standard ones as I am a bit confused why they are not 64 or 512?

Edit: also do you know if it buffers if you don't call usbcdc_rxcallback() before the next usb packet arrives?

[Folknology]

Do we have HS on the board?

The chip we use doesn't have a HS PHY, it basically uses an FS PHY, although one could add an external HS PHY like a 3300. On some variants of this chip a HS PHY is in the package..

I do know that the timing of USB data can be all over the place so wondered if the STM usb stuff will sometimes be buffering up packets and sending multiple to usbcdc_rxcallback().

Don't think you can assume the size the usbcallback hands youm, but it is normally 64bytes unless it's the end of a packet that doesn't divide into 64 or it's a packel less than 64 total..

Edit: also do you know if it buffers if you don't call usbcdc_rxcallback() before the next usb packet arrives?

I think you are ok with the buffers until you call USBD_CDC_ReceivePacket(&hUsbDeviceFS) AFAIK but don't quote me on that..

[Folknology]

Did you create those defines or are they standard ones as I am a bit confused why they are not 64 or 512?

I think these are MxCube defaults..

[Folknology]

BTW I think I have the interrupt priorities working now (For systick calls within interrupts for SPI etc..), although I still get some weird stuff with the flash interrogation...

[AndyCap]

Super, thanks for the info.

Probably best to play it save and think we could get more than 64 as well then.

I'm just thinking the easiest way is just to:

1. Call CommandHandler.RegisterData(data, len) in usbcdc_rxcallback(). Do NOT call USBD_CDC_ReceivePacket().
2. In loop() call CommandHandler.ProcessRegisteredData(). When data is processed call USBD_CDC_ReceivePacket()

I will knock this up and test by adding random pauses (>1ms) in loop() to see if it works.

[AndyCap]

BTW I think I have the interrupt priorities working now (For systick calls within interrupts for SPI etc..), although I still get some weird stuff with the flash interrogation...

Aha, even better. Maybe I don't need to write any code
What have you added?

[Folknology]

I am in the middle of writing Flash code to program it, but that isn't yet tested, however I needed to solve the Interrupt priority issues as my flash code has a 'Stream' Method that is expected to be called within the USBRXCallback, I haven't pushed the changes yet as I am still doing battle with this weird Flash/boot issue.

I can push it if you want to play..

[AndyCap]

That would be good, or just post here the calls to set up the interrupt priority stuff and I can merge that into my stuff.

I'm happy just to stop it hanging in the SPI stuff when I do something in the wrong order!

Also I have the flash stuff "implemented", ie. basic writing and reading and flashing the bitstream if you would like it to save some time:

<was just about to give link in GitHub for files but not there, just a sec)

[AndyCap]

No idea what is going on with GitHub, none of my changes are there!

Here is the code I have been using though:

/*
 * CADFlashHandler.cpp
 *
 *  Created on: 2 Aug 2019
 *      Author: andrewcapon
 */

#include "CADFlashHandler.h"
#include "mystorm.h"

CADFlashHandler::CADFlashHandler(SPI_HandleTypeDef *hspi)
{
	spi = hspi;
}

#define MYTIMEOUT 1000

uint8_t CADFlashHandler::write(uint8_t *p, uint32_t len)
{
	return HAL_SPI_Transmit(spi, p, len, MYTIMEOUT);
}

uint8_t CADFlashHandler::read(uint8_t *p, uint32_t len)
{
	return HAL_SPI_Receive(spi, p, len, MYTIMEOUT);
}

uint8_t CADFlashHandler::write_read(uint8_t *tx, uint8_t *rx, uint32_t len)
{
	return HAL_SPI_TransmitReceive(spi, tx, rx, len, MYTIMEOUT);
}

void CADFlashHandler::Enable(void)
{
	release_flash();
	free_flash();
	flash_SPI_Enable();

	uint8_t uCommand = 0xAB;
	gpio_low (ICE40_SPI_CS);
	write(&uCommand, 1);
	gpio_high(ICE40_SPI_CS);
}

void CADFlashHandler::Disable(void)
{
	flash_SPI_Disable();
}

bool CADFlashHandler::CheckId(void)
{
	Enable();

	uint8_t uCommand = 0x9F;
	uint8_t response[3] = { 0, 0, 0 };

	gpio_low (ICE40_SPI_CS);
	write(&uCommand, 1);
	read(response, 3);
	gpio_high(ICE40_SPI_CS);

	Disable();

	return ((response[0] == 0x1F) && (response[1] == 0x84) && (response[2] == 0x01));
}

bool CADFlashHandler::init(uint8_t uSubCommand)
{
	bool bResult = false;

	if (CheckId())
	{
		switch(uSubCommand)
		{
			case 0: // erase flash
				EraseFlash();
				bResult = false;
			break;

			case 1: // Program flash with bitsream
				Erase64K(0);
				Erase64K(1);
				Erase64K(2);
				bResult = true;
			break;

			case 2: // Query flash
					cdc_puts((char *)"AT25SF041 Flash Found\n");
			break;

			default:
				bResult = false;
		}
	}
	else
		cdc_puts((char *)"Error: AT25SF041 Flash NotFound\n");


	return bResult;
}

void CADFlashHandler::InitBufferedWrite(void)
{
	m_uTotalBytes = 0;
	m_uCur256BytePage = 0;
	m_uBufferPos = 0;
}

void CADFlashHandler::BufferedWrite(uint8_t *pData, uint32_t uLen)
{
	m_uTotalBytes += uLen;

	while (uLen)
	{
		uint16_t uRemaining = 256 - m_uBufferPos;
		if (uLen < uRemaining)
		{
			memcpy(m_buffer + m_uBufferPos, pData, uLen);
			m_uBufferPos += uLen;
			uLen = 0;
		}
		else
		{
			memcpy(m_buffer + m_uBufferPos, pData, uRemaining);
			m_uBufferPos += uRemaining;
			pData += uRemaining;
			uLen -= uRemaining;
		}

		if (m_uBufferPos == 256)
		{
			// ok write to flash
			WritePage(m_uCur256BytePage, m_buffer);

			m_uCur256BytePage++;
			m_uBufferPos = 0;
		}

	}
}

void CADFlashHandler::FlushBuffer(void)
{
	if (m_uBufferPos)
		WritePage(m_uCur256BytePage, m_buffer);
}

bool CADFlashHandler::streamData(uint8_t *data, uint32_t len, bool bEndStream)
{
	bool bResult = true;

	if (!m_uTotalBytes) // bodge lookat doing properly
	{
		// skip 4 byte header
		data += 4;
		len -= 4;
	}

	BufferedWrite(data, len);

	if (bEndStream || (m_uTotalBytes >= (IMGSIZE)))
	{
//		if(err = config())
//			status_led_high();
//		else
//			status_led_low();

		FlushBuffer();
		bResult = false;
	}

	return bResult;

}

bool CADFlashHandler::IsReady(void)
{

	Enable();
	uint8_t uCommand = 0x05;
	uint8_t response;

	gpio_low (ICE40_SPI_CS);
	write(&uCommand, 1);
	read(&response, 1);
	gpio_high(ICE40_SPI_CS);

	Disable();

	return (!(response & 1));
}

void CADFlashHandler::PollForReady(void)
{
	while (!IsReady())
		;
}

bool CADFlashHandler::WritePage(uint16_t uPage, uint8_t *pData)
{
	WriteEnable();

	uint8_t uMSB = (uPage >> 8) & 0xFF;
	uint8_t uLSB = uPage & 0xFF;

	gpio_low (ICE40_SPI_CS);
	uint8_t command[4] = { 0x02, uMSB, uLSB, 0x00 };
	write(command, 4);

	write(pData, 256);
	gpio_high(ICE40_SPI_CS);

	Disable();

	PollForReady();

	return(true);
}

bool CADFlashHandler::ReadPage(uint16_t uPage, uint8_t *pData)
{
	Enable();

	uint8_t uMSB = (uPage >> 8) & 0xFF;
	uint8_t uLSB = uPage & 0xFF;

	gpio_low (ICE40_SPI_CS);
	uint8_t command[4] = { 0x03, uMSB, uLSB, 0x00 };
	write(command, 4);

	read(pData, 256);
	gpio_high(ICE40_SPI_CS);

	Disable();
	return(true);
}

bool CADFlashHandler::WriteData(uint32_t uAddr, uint8_t *pData, uint32_t uLen)
{
	WriteEnable();

	// just address 0 at the moment
	gpio_low (ICE40_SPI_CS);
	uint8_t command[4] = { 0x02, 0x00, 0x00, 0x00 };
	write(command, 4);

	write(pData, uLen);
	gpio_high(ICE40_SPI_CS);

	Disable();

	PollForReady();
	return(true);
}

bool CADFlashHandler::ReadData(uint32_t uAddr, uint8_t *pData, uint32_t uLen)
{
	PollForReady();

	Enable();

	// just address 0 at the moment
	gpio_low (ICE40_SPI_CS);
	uint8_t command[4] = { 0x03, 0x00, 0x00, 0x00 };
	write(command, 4);

	read(pData, uLen);
	gpio_high(ICE40_SPI_CS);

	Disable();
	return(true);
}

void CADFlashHandler::WriteEnable(void)
{
	Enable();

	uint8_t uCommand = 0x06;

	gpio_low (ICE40_SPI_CS);
	write(&uCommand, 1);
	gpio_high(ICE40_SPI_CS);

}

void CADFlashHandler::EraseFlash(void)
{
	PollForReady();

	WriteEnable();

	uint8_t uCommand = 0x60;

	gpio_low (ICE40_SPI_CS);
	write(&uCommand, 1);
	gpio_high(ICE40_SPI_CS);

	Disable();

	PollForReady();

}

void CADFlashHandler::Erase64K(uint8_t uPage)
{
	PollForReady();

	WriteEnable();

	uint8_t command[] = { 0xD8, uPage, 0, 0 };

	gpio_low (ICE40_SPI_CS);
	write(command, 4);
	gpio_high(ICE40_SPI_CS);

	Disable();

	PollForReady();

}

[Folknology]

That would be good, or just post here the calls to set up the interrupt priority stuff and I can merge that into my stuff.

I'm happy just to stop it hanging in the SPI stuff when I do something in the wrong order!

Just pushed those changes including the non-working flash code, have a play..

BTW the mode button toggles program destination from Ice40 to flash so avoid pressing it..

[AndyCap]

Thanks.

I will have a look now...