ADSYCR register dereference structure error

[njoudyk]

In FSP 5.1 (and possibly earlier versions), the dereference structure for the 'ADSYCR' register bit mapping in 'r_adc_b.' has an error. https://github.com/renesas/fsp/blob/49346c0731c7513a33610a748af590a671a6fab2/ra/fsp/inc/instances/r_adc_b.h#L593-L604

The register has 11 bits for 'ADSYCYC', 5 spare bits, 'ADSYDIS0', 'ADSYDIS1' and 14 more spare bits, according to the datasheet for my chip (RA6T2). (https://www.renesas.com/us/en/document/mah/ra6t2-group-users-manual-hardware?r=1542426 36.2.1.4), while the dereference structure has 10 bits for 'ADSYCYC', 5 spare, 'ADSYDIS0', 'ADSYDIS1' and then 15 more spare bits.

The generated 'hal_data.c' file has the correct bit mapping ('ADSYDIS0', 'ADSYDIS1' bits shifted to positions 16/17, respectively), so the actual ADC register will be configured properly but if 'Parameter Checking' is enabled in the ADC driver module in the FSP package, the generated code uses the de-reference structure to check the sync disable bits, and thus dereferenced 'ADSYDIS0' bit will always be 0, and the dereferenced 'ADSYDIS1' bit will be 'ADSYDIS0'. This can and will lead to an error where the FSP configuration has synchronous operation disabled for both ADC channels (and thus doesn't need to be validated with parameter checking), but the code generated that references these bits will assume channel zero has synchronous operation enabled.

As far as I can tell, this is only used in the 'R_ADC_B_ScanCfg' function and 'adc_b_calculate_wait_time' but it can cause scan configuration to fail depending on the configured calibration.

As a side note - there are a few initialization/open function calls in the 'RM_MOTOR_DRIVER_Open' function call that do not return errors on failure, and ignore the return value of sub-module initialization, including 'rm_motor_driver_adc_b_open'. This can lead to the motor driver claiming that it is open and functioning with no errors, but with API calls not doing anything (as the cyclic callback on the ADC channel scan complete is never triggered after the scan config fails).

This made troubleshooting this error very frustrating - the only difference between my FSP configuration and the sample 'quickstart_mck_ra6t2_ep' project was that the Default BSP configuration had parameter checking enabled, but the identical motor control code/logic did absolutely nothing while reporting everything was fine.

[renesas-brandon-hussey]

This is being internally tracked using FSPRA-2494.

[renesas-brandon-hussey]

The issue related to the rm_motor_driver module not checking return codes is internally tracked using FSPRA-2495.

[renesas-austin-hansen]

The ADSYCR mapping issue (FSPRA-2494) will be resolved in RA FSP v5.2.0.