KL27 Dedicated USB ram?

[tonymakkiel]

Hi,

             Where can I read more about the KL27 dedicated USB ram? Is it specific to KL27 64kB freedom board? Or is it present in all KL27 varients? As per the  ld file it is 512 bytes from "0x040FE000"

m_usb_sram            (RW)  : ORIGIN = 0x040FE000, LENGTH = 0x00000200.

It also looks like it is out of  SRAM range as well ( 1FFFDFFF - 20006000 )?

Many Thanks,

Tony

[tonymakkiel]

Thank you for the information Bob and Mark. 

That explains why I was getting a hardfault on KL27Z256 variant and not in the freedom board.

[mjbcswitzerland · Accepted solution]

Tony

The 512 byte USB RAM is available in KL27Z32 and KL27Z64 parts - not in the larger KL27Z128 and KL27Z256 ones.

Its intended use is in Keep Alive mode - there is a section in the user's manual explaining this. It is only valid for device-only and allows the USB to be kept alive in STOP/VLPS modes by allowing the USB controller to remain connected to the bus and respond with NAKs. It can be woken when it receives certain TOKENs from the host. The 512 block remains available to the USB device controller in this low power state so that it can essentially continue doing minimal things in order to not need to disconnect from the bus when the chip enters low power mode.

If not used for this the 512 bytes are available for other is in RUN mode.

Regards

Mark

[bobpaddock]

It does not have dedicated RAM.

/******************************************************************************
* BUFFER DISCRIPTOR TABLE (BDT) DISCRIPTION *
******************************************************************************/
/**
* The USB-FS implements a Buffer Descriptor Table (BDT) in system memory. The
* BDT resides on a 512 byte boundary in system memory and is pointed to by the
* BDT Page Registers. Every endpoint direction requires two eight-byte Buffer
* Descriptor entries.Therefore, a system with 16 fully bidirectional endpoints
* would require 512 bytes of system memory to implement the BDT.The two Buffer
* Descriptor (BD) entries allows for an EVEN BD and ODD BD entry for each
* endpoint direction. This allows the microprocessor to process one BD while
* the USB-FS is processing the other BD. Double buffering BDs in this way
* allows the USB-FS to easily transfer data at the maximum throughput provided
* by USB.
* ...

This tells the USB module what 512 byte block to use:

/*
* Set address bits of the base address where the current Buffer
* Descriptor Table (BDT) resides in system memory.
* Must to be on 512 byte boundary.
* D8 Bit is masked in BDT_PAGE_01.
*/
USB0_BDTPAGE1 = ( ( uint8_t )( ( uint32_t ) bdt >> 8U ) & 0xFEU );
USB0_BDTPAGE2 = ( uint8_t )( ( uint32_t ) bdt >> 16U );
USB0_BDTPAGE3 = ( uint8_t )( ( uint32_t ) bdt >> 24U );

The KL USB module is a decedent of a ColdFire module which traces its linage back to some purchased IP from a third party.  Many chips have similar module.  The PIC32 data sheet does a better job explaining things in places of how it works.  All of the register names are of course different.

http://ww1.microchip.com/downloads/en/DeviceDoc/61126F.pdf 

Something to watch for in Linker scripts are something are specified in Words an other things in Bytes.

Happens more in 8-bit parts like the AVR.

However that does not appear to be the case for the two values you show.