Due to the U.S. Thanksgiving holiday, please expect delayed responses during the week of 11/22.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

tm4c123be6pz: TMC4C123 CRC ROM function versus TMC4129 CRC peripheral

Part Number: TM4C123BE6PZ

I am evolving my implementation of a CRC algorithm. 

I have bootloaders that calculates a CRC and compares to one found in the FLASH.  If they are the same, then the bootloader jumps to the application.

I originally just used the CRC16-XMODEM (+2 zero bytes) code used by IAR on AVR targets.  As we move to larger FLASH, this is getting to be too slow.

TMC4C123's ROM code uses CRC16-IBM.

TMC4C129's peripheral uses CRC16-XMODEM.

Why were two different algorithm's chosen?

I notice that the speed performance between the two implementations are essentially the same.  Are they the same? 

I would have assumed the ROM code would be just that and probably about as fast as an optimized algorithm (it is markedly faster). 

I would have assumed the peripheral would use a bunch of custom transistors to find impressive speed.

  • Hi John,

    The CRC16-IBM in TM4C123 is a software based CRC calculation with the algorithm preprogrammed in the ROM while the CRC16-XMODEM is a hardware based CRC calculation. The performance of the hardware based CRC engine will be significantly faster than the software based. Did you use the hardware based CRC in the TM4C129? The TM4C129 also has the CRC algorithm implemented in the ROM backward compatibility. But if you want the performance you should use the hardware based CRC. Please refer to the CRC module in the datasheet.
  • No solution for you but I do have a question. What timing are you seeing? I'm sure I'm not the only curious observer

    Robert
  • Thanks for the reply. I now see that the peripheral provides the same CRC16-IBM that the ROM does, at least it looks like the polynomial is the same. So my first question is answered - or perhaps it should have not have been asked.

    But I am confused by the second answer. I used the CRC API defined in SW-TM4C-DRL-UG-2.1.1.71. I thought this would use the HW peripheral and not the ROM call. I am getting the same performance using the ROM call on a TM4C123 and a TivaWare call on a 129.

    The TivaWare example is using the HW, correct?

    I based my code off of the crc32 project found in the TM4C connected Launchpad.
  • Hi John,
    I assume you use ROM_Crc16() or ROM_Crc16Array() in TM4C123 to calculate the CRC while using CRCDataProcess() API to calculate the same CRC in TM4C129, right?
  • ROM_Crc16 on the TM4C123.
    ROM_CRCDataProcess (as in the crc32.c example) for the TM4C129.
  • Can you show your measurements between the two? I'm very surprised there is no difference. What is the length of input data for each case? The crc32 example even uses the DMA to input the data into the CRC module and this is supposed to be even more efficient than the CPU to send data to the CRC module.
  • 'Can you show your measurements between...'

    Charles, I am sorry for the delay in response.

    We have monitors (aka bootloaders) of 24 and 32KB size.  The 128, 256, 1024 numbers indicate the total flash size.  So the time to CRC is FLASH size - monitor size - 2pages.  The only experimental data, found by toggling a pin and tracking on an oscilloscope, is the Time/page (msec) in the second column.   The percentage of monitor FLASH columns is an attempt to weigh size vs speed.

    The question that remains in my mind is how my data indicates that the peripheral and ROM take the same amount of time.  My assumption is that the peripheral actually uses very clever silicon to compute that CRC and should be faster than the ROM'ed code.  But I have gone back and review my code and I do not believe I have a mistake.  They are the same duration.

    Good luck and hope this is useful.  Let me know if you find different results for peripheral vs ROM.

  • Hi John,
    Thanks for running the benchmark.

    How is the CRC16 ROM Call different from the CRC16 Code or even the CRC16 Optimized Code?