 |
RTEMS 6.1-rc2
|
Loading...
Searching...
No Matches
|
RTEMS 6.1-rc2
|
HASH HAL module driver. This file provides firmware functions to manage the following functionalities of the HASH peripheral: More...
#include "stm32h7xx_hal.h"HASH HAL module driver. This file provides firmware functions to manage the following functionalities of the HASH peripheral:
Copyright (c) 2017 STMicroelectronics. All rights reserved.
This software is licensed under terms that can be found in the LICENSE file in the root directory of this software component. If no LICENSE file comes with this software, it is provided AS-IS.
===============================================================================
##### How to use this driver #####
===============================================================================
[..]
The HASH HAL driver can be used as follows:
(#)Initialize the HASH low level resources by implementing the HAL_HASH_MspInit():
(##) Enable the HASH interface clock using __HASH_CLK_ENABLE()
(##) When resorting to interrupt-based APIs (e.g. HAL_HASH_xxx_Start_IT())
(+++) Configure the HASH interrupt priority using HAL_NVIC_SetPriority()
(+++) Enable the HASH IRQ handler using HAL_NVIC_EnableIRQ()
(+++) In HASH IRQ handler, call HAL_HASH_IRQHandler() API
(##) When resorting to DMA-based APIs (e.g. HAL_HASH_xxx_Start_DMA())
(+++) Enable the DMAx interface clock using
__DMAx_CLK_ENABLE()
(+++) Configure and enable one DMA stream to manage data transfer from
memory to peripheral (input stream). Managing data transfer from
peripheral to memory can be performed only using CPU.
(+++) Associate the initialized DMA handle to the HASH DMA handle
using __HAL_LINKDMA()
(+++) Configure the priority and enable the NVIC for the transfer complete
interrupt on the DMA stream: use
HAL_NVIC_SetPriority() and
HAL_NVIC_EnableIRQ()
(#)Initialize the HASH HAL using HAL_HASH_Init(). This function:
(##) resorts to HAL_HASH_MspInit() for low-level initialization,
(##) configures the data type: 1-bit, 8-bit, 16-bit or 32-bit.
(#)Three processing schemes are available:
(##) Polling mode: processing APIs are blocking functions
i.e. they process the data and wait till the digest computation is finished,
e.g. HAL_HASH_xxx_Start() for HASH or HAL_HMAC_xxx_Start() for HMAC
(##) Interrupt mode: processing APIs are not blocking functions
i.e. they process the data under interrupt,
e.g. HAL_HASH_xxx_Start_IT() for HASH or HAL_HMAC_xxx_Start_IT() for HMAC
(##) DMA mode: processing APIs are not blocking functions and the CPU is
not used for data transfer i.e. the data transfer is ensured by DMA,
e.g. HAL_HASH_xxx_Start_DMA() for HASH or HAL_HMAC_xxx_Start_DMA()
for HMAC. Note that in DMA mode, a call to HAL_HASH_xxx_Finish()
is then required to retrieve the digest.
(#)When the processing function is called after HAL_HASH_Init(), the HASH peripheral is
initialized and processes the buffer fed in input. When the input data have all been
fed to the Peripheral, the digest computation can start.
(#)Multi-buffer processing is possible in polling, interrupt and DMA modes.
(##) In polling mode, only multi-buffer HASH processing is possible.
API HAL_HASH_xxx_Accumulate() must be called for each input buffer, except for the last one.
User must resort to HAL_HASH_xxx_Accumulate_End() to enter the last one and retrieve as
well the computed digest.
(##) In interrupt mode, API HAL_HASH_xxx_Accumulate_IT() must be called for each input buffer,
except for the last one.
User must resort to HAL_HASH_xxx_Accumulate_End_IT() to enter the last one and retrieve as
well the computed digest.
(##) In DMA mode, multi-buffer HASH and HMAC processing are possible.
(+++) HASH processing: once initialization is done, MDMAT bit must be set
through __HAL_HASH_SET_MDMAT() macro.
From that point, each buffer can be fed to the Peripheral through HAL_HASH_xxx_Start_DMA() API.
Before entering the last buffer, reset the MDMAT bit with __HAL_HASH_RESET_MDMAT()
macro then wrap-up the HASH processing in feeding the last input buffer through the
same API HAL_HASH_xxx_Start_DMA(). The digest can then be retrieved with a call to
API HAL_HASH_xxx_Finish().
(+++) HMAC processing (requires to resort to extended functions):
after initialization, the key and the first input buffer are entered
in the Peripheral with the API HAL_HMACEx_xxx_Step1_2_DMA(). This carries out HMAC step 1 and
starts step 2.
The following buffers are next entered with the API HAL_HMACEx_xxx_Step2_DMA(). At this
point, the HMAC processing is still carrying out step 2.
Then, step 2 for the last input buffer and step 3 are carried out by a single call
to HAL_HMACEx_xxx_Step2_3_DMA().
The digest can finally be retrieved with a call to API HAL_HASH_xxx_Finish().
(#)Context swapping.
(##) Two APIs are available to suspend HASH or HMAC processing:
(+++) HAL_HASH_SwFeed_ProcessSuspend() when data are entered by software (polling or IT mode),
(+++) HAL_HASH_DMAFeed_ProcessSuspend() when data are entered by DMA.
(##) When HASH or HMAC processing is suspended, HAL_HASH_ContextSaving() allows
to save in memory the Peripheral context. This context can be restored afterwards
to resume the HASH processing thanks to HAL_HASH_ContextRestoring().
(##) Once the HASH Peripheral has been restored to the same configuration as that at suspension
time, processing can be restarted with the same API call (same API, same handle,
same parameters) as done before the suspension. Relevant parameters to restart at
the proper location are internally saved in the HASH handle.
(#)Call HAL_HASH_DeInit() to deinitialize the HASH peripheral.
*** Remarks on message length ***
===================================
[..]
(#) HAL in interruption mode (interruptions driven)
(##)Due to HASH peripheral hardware design, the peripheral interruption is triggered every 64 bytes.
This is why, for driver implementation simplicity’s sake, user is requested to enter a message the
length of which is a multiple of 4 bytes.
(##) When the message length (in bytes) is not a multiple of words, a specific field exists in HASH_STR
to specify which bits to discard at the end of the complete message to process only the message bits
and not extra bits.
(##) If user needs to perform a hash computation of a large input buffer that is spread around various places
in memory and where each piece of this input buffer is not necessarily a multiple of 4 bytes in size, it becomes
necessary to use a temporary buffer to format the data accordingly before feeding them to the Peripheral.
It is advised to the user to
(+++) achieve the first formatting operation by software then enter the data
(+++) while the Peripheral is processing the first input set, carry out the second formatting
operation by software, to be ready when DINIS occurs.
(+++) repeat step 2 until the whole message is processed.
[..]
(#) HAL in DMA mode
(##) Again, due to hardware design, the DMA transfer to feed the data can only be done on a word-basis.
The same field described above in HASH_STR is used to specify which bits to discard at the end of the
DMA transfer to process only the message bits and not extra bits. Due to hardware implementation,
this is possible only at the end of the complete message. When several DMA transfers are needed to
enter the message, this is not applicable at the end of the intermediary transfers.
(##) Similarly to the interruption-driven mode, it is suggested to the user to format the consecutive
chunks of data by software while the DMA transfer and processing is on-going for the first parts of
the message. Due to the 32-bit alignment required for the DMA transfer, it is underlined that the
software formatting operation is more complex than in the IT mode.
*** Callback registration ***
===================================
[..]
(#) The compilation define USE_HAL_HASH_REGISTER_CALLBACKS when set to 1
allows the user to configure dynamically the driver callbacks.
Use function HAL_HASH_RegisterCallback() to register a user callback.
(#) Function HAL_HASH_RegisterCallback() allows to register following callbacks:
(+) InCpltCallback : callback for input completion.
(+) DgstCpltCallback : callback for digest computation completion.
(+) ErrorCallback : callback for error.
(+) MspInitCallback : HASH MspInit.
(+) MspDeInitCallback : HASH MspDeInit.
This function takes as parameters the HAL peripheral handle, the Callback ID
and a pointer to the user callback function.
(#) Use function HAL_HASH_UnRegisterCallback() to reset a callback to the default
weak (surcharged) function.
HAL_HASH_UnRegisterCallback() takes as parameters the HAL peripheral handle,
and the Callback ID.
This function allows to reset following callbacks:
(+) InCpltCallback : callback for input completion.
(+) DgstCpltCallback : callback for digest computation completion.
(+) ErrorCallback : callback for error.
(+) MspInitCallback : HASH MspInit.
(+) MspDeInitCallback : HASH MspDeInit.
(#) By default, after the HAL_HASH_Init and if the state is HAL_HASH_STATE_RESET
all callbacks are reset to the corresponding legacy weak (surcharged) functions:
examples HAL_HASH_InCpltCallback(), HAL_HASH_DgstCpltCallback()
Exception done for MspInit and MspDeInit callbacks that are respectively
reset to the legacy weak (surcharged) functions in the HAL_HASH_Init
and HAL_HASH_DeInit only when these callbacks are null (not registered beforehand)
If not, MspInit or MspDeInit are not null, the HAL_HASH_Init and HAL_HASH_DeInit
keep and use the user MspInit/MspDeInit callbacks (registered beforehand).
Callbacks can be registered/unregistered in READY state only.
Exception done for MspInit/MspDeInit callbacks that can be registered/unregistered
in READY or RESET state, thus registered (user) MspInit/DeInit callbacks can be used
during the Init/DeInit.
In that case first register the MspInit/MspDeInit user callbacks
using HAL_HASH_RegisterCallback before calling HAL_HASH_DeInit
or HAL_HASH_Init function.
When The compilation define USE_HAL_HASH_REGISTER_CALLBACKS is set to 0 or
not defined, the callback registering feature is not available
and weak (surcharged) callbacks are used. 
1.9.6