SAME70 USB + CACHE

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I have a problem using USB on the SAME70 Xplained board.

 

If I compile the SAME70_CDC_EXAMPLE as it stands then the USB connects.

If I enable the caches using BOARD_ENABLE_CACHE then the PC end says that the USB device has malfunctioned.

 

Any ideas?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If dma is used, then the cache rows in question need to be invalidated. Don't ask me how you do this on a e70.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure if DMA is being used or not as I am using the Atmel supplied ASF component to handle the USB.

I would have expected the cache invalidation etc. to be handled in the library?

 

I have the same problem in my application but as it happens also in an unmodified example I don't think it is because of anything that I have done.

However there may be something I can do about it if I can work out exactly what.

 

Thanks

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

 

I do have the same problem: CONF_BOARD_ENABLE_CACHE is needed to make e.g. the SD/MMC driver work, but it blocks the USB (MSC service in my case) from working properly. And of course I need both together.

I filed a bug report about (http://asf.atmel.com/bugzilla/sh...) and have been answered the problem being "in the backlog of ASF list", whatever that means.

 

Has anybody found out how to solve the issue?

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not expert regarding DCache. But I think using DMA and DCache togehter is probably quite tricky and needs well written drivers. I made the same observation, that ASF USB MSC Service does not work with DCache enabled.

As a workarround you can just enable the ICache by calling SCB_EnableICache in your code. This will already give you a significant performance boost in and it worked for me with USB MSC.

SD-Card driver worked for me also with all Caches disabled, I cannot see how it needs CONF_BOARD_ENABLE_CACHE to work properly.

 

Apart from this: In some Headerfile there was missing a #define for the E70 to use High-Speed USB. This was at AS7 build 790....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi adjsw,

 

thanks for your reply. I tried your workarround, but unfortunately it doesn´t do the trick for me.

 

Have you used the SD-Card driver for SPI or for MCI?

 

I use MCI, which definitely needs both I- and D-cache to be enabled. 

Also I have no Idea how to setup the SPI driver on the SAME70 Xplained board, since the pins for the SD-Card slot are not connecting to any SPI port. Or is there something I ignore?

 

In any case, thank you very much!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I was using MCI both with DVK and also with a custom design. No problem without Caches. I can also not see why the caches would be necessary, they are bascically just a performance boost to hide main memory latencies.

Are you also on a SAME70 platform?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

 

Regarding SAME70 and the SAME70 Xplained board: Atmel checked for the bug I filed and setup a temporary solution which allows to run the SD-Card (MCI) without cache (exactly that was not possible before).

The details can be found here: http://asf.atmel.com/bugzilla/sh...

 

Thanks to everybody for the help!

 

I was using MCI both with DVK and also with a custom design. No problem without Caches. 

I guess there is some further development under way to implement the (SAME70 ?) cache in the ASF and the problem arose only recently. As said in the bug report, at Atmel they are working to enable the cache also for USB. Since I can live without using the cache, to me this fix is fine.

Last Edited: Thu. Sep 8, 2016 - 12:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

We are still affected by this issue and I just wanted to ask if there was any progress done on this ? I event tried to use the USB stack form the Atmel Software pack 1.5 instead of the one found in Atmel Studio, but the issue persist - I can't enumerate a usb device when operating as a host.

 

Marko

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, this http://asf.atmel.com/bugzilla/show_bug.cgi?id=3747 bug seems still to be valid... sad

I also tried USB Host Vendor example adapted for SAME70-XPLD board and it didn't work when CONF_BOARD_ENABLE_CACHE is defined.

In \src\ASF\sam\drivers\usbhs\usbhs_host.c, the example has CONF_BOARD_ENABLE_CACHE_AT_INIT (notice the different name) but defining it doesn't help: both RX and TX are affected.

For example at TX tried combinations of one or even both of the following (immediately after preparing the TX buffer, main_vendor_buf_out) but it didn't work:

_dcache_flush(main_vendor_buf_out, len /* tried even with full length 1024 */ );
_dcache_flush((void *)USBHS_RAM_ADDR, UHD_PIPE_MAX_TRANS); // 0xA0100000,0x8000=32KB

Same at RX no luck with any of these:

_dcache_invalidate(main_vendor_buf_in, in_payload_trans /* tried even with full length 1024, but the same */ );
_dcache_invalidate((void *)USBHS_RAM_ADDR, UHD_PIPE_MAX_TRANS); // 0xA0100000,0x8000=32KB

 

 

The first workaround was to flush whole d-cache: SCB_CleanDCache before USB TX, respectively flush+invalidate SCB_CleanInvalidateDCache after USB RX.

But this defeats the d-cache purpose (to flush 32KB entirely when I want to send just 49 bytes...).

 

 

The second workaround was to place the RX/TX buffers in a non-cacheable area:

//! Output buffer for vendor class test
#if defined MPU_HAS_NOCACHE_REGION
COMPILER_SECTION(".ram_usbnocache")
#else
COMPILER_ALIGNED(32)
#endif // MPU_HAS_NOCACHE_REGION
static uint16_t main_vendor_buf_out[MAIN_VENDOR_LOOPBACK_SIZE];

Where the area "ram_usbnocache" is defined in src\ASF\sam\utils\linker_scripts\same70\same70q21\gcc\flash.ld:

MEMORY
{
  rom (rx)  : ORIGIN = 0x00400000, LENGTH = 0x00200000
  ram (rwx) : ORIGIN = 0x20400000, LENGTH = 0x0005f000
  /* For ram_usbnocache, see MPU_HAS_NOCACHE_REGION and NOCACHE_SRAM_REGION_SIZE */
  ram_usbnocache (rwx) : ORIGIN = 0x2045f000, LENGTH = 0x00001000
}


/* Section Definitions */
SECTIONS
{
    .text :
    {
        ...
    } > rom

    /* heap section */
    .heap (NOLOAD):
    {
        ...
    } > ram

    /* For ram_usbnocache, see MPU_HAS_NOCACHE_REGION and NOCACHE_SRAM_REGION_SIZE */
    .ram_usbnocache (NOLOAD) :
    {
        . = ALIGN(32);
        *(.ram_usbnocache);
    } > ram_usbnocache 

    . = ALIGN(4);
    _end = . ;
    _ram_end_ = ORIGIN(ram) + LENGTH(ram) -1 ;
}

Ensure these in conf_board.h:

#define CONF_BOARD_ENABLE_CACHE
#define MPU_HAS_NOCACHE_REGION
#define CONF_BOARD_CONFIG_MPU_AT_INIT

Also in src\ASF\sam\drivers\mpu\mpu.h (needed in src\ASF\sam\boards\same70_xplained\init.c):

#define INNER_OUTER_NORMAL_NOCACHE_TYPE(x)  ((0x01 << MPU_RASR_TEX_Pos) | (DISABLE << MPU_RASR_C_Pos) | (DISABLE << MPU_RASR_B_Pos) | (x << MPU_RASR_S_Pos))

And in src\ASF\sam\boards\same70_xplained\init.c replace CONF_BOARD_ENABLE_CACHE_AT_INIT with CONF_BOARD_ENABLE_CACHE.

With these DCache is enabled but USB uses non-cacheable buffer and works reliably!

 

 

All above I tried with the (not so) old ASF 3.38 example. But I also tried the "USB Host Vendor" example from the new ASF4 (aka Atmel START: http://start.atmel.com) but there no more DCache at all (searching for SCB_Invalidate or SCB_Clean and no usage except their definitions from \CMSIS\Include\core_cm7.h). This complete avoidance of cache as well as the silence from the mentioned bugzilla entry could indicate some known but not yet public HW trouble in SAME70 (at least revision A)?

At least couldn't see anything in errata related to USB/DMA/DCACHE... I ordered few E70 revision B free samples and if they'll arrive our HW engineer will solder on the evaluation board but I doubt it will change anything.

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try this (just copied it from my init.c):

 

#ifdef CONF_BOARD_ENABLE_CACHE
	/* Enabling the Cache */
	SCB_EnableICache(); 
	SCB_EnableDCache();		//We are using multiple DMA masters so disable data cache to avoid constant cleaning (before) and invalidation (after) DMA transfers.
							//See Atmel AT17417: Usage of XDMAC on SAM S/SAM E/SAM V [APPLICATION NOTE] pg.29 for details
							
							//However, if we do not momentarily enable cache, the XDMAC does not do anything at all with SPI! 
							//So we enable it momentarily and then disable again. 
	SCB_DisableDCache();
	SCB_DisableICache();
		
#endif

 

For whatever reason I found the system way more stable from DMA perspective when I enable and then disable the cache, rather than just disabling it or not doing anything at all.

I have working setup with SAME70Q21 where DMA memory is located in external SDRAM chip, SPI (slave mode) clocks in data into that memory through XDMAC and SSC controller (also in slave mode) clocks data out from that pool, in parallel, using XDMAC as well. The throughput is 2.5Mbit/s realtime.

 

The only circumstance it fails is when I do excessive ioport access at the same time. Then the SPI DMA transfer starts skipping bits. Not sure yet why this is happening..

 

Regards,

 

Andrus.