Hello,
Just noticed this issue and was wondering if it is intended. When working with the R_USB_ClassTypeGet you should write the value of p_ctrl->type to the address of the given usb_class_t pointer. However usb_class_t enum starts at the value 0x80 whereas p_ctrl->type gives a value that is 128 lower due to a piece of code where it lowers its usb_class_t value for the usb_class_internal_t enum. When you request the value for comparison in code you will receive the usb_class_internal_t value written to usb_class_t which breaks checks for which class is active. Small example:
usb_class_t USBInfo; R_USB_ClassTypeGet(&g_basic0_ctrl, &USBInfo); if(USBInfo == USB_CLASS_HCDC){ // This should be valid However the value of USBInfo is 7 (USB_CLASS_INTERNAL_HCDC) instead of 135 (USB_CLASS_HCDC) //Therefore this fails } return USBInfo;
usb_class_t USBInfo; R_USB_ClassTypeGet(&g_basic0_ctrl, &USBInfo); if(USBInfo == USB_CLASS_HCDC){
// This should be valid However the value of USBInfo is 7 (USB_CLASS_INTERNAL_HCDC) instead of 135 (USB_CLASS_HCDC)
//Therefore this fails
} return USBInfo;
Solution is obviously to count 128 back to the value given by R_USB_ClassTypeGet but this seems like unintended behaviour since you request a value of type usb_class_t and get usb_class_internal_t and no comment explaining that you need to do this.
I see what you mean, I have reported this to the FSP development team.
This discrepancy happens on this line in r_usb_basic.c p_ctrl->type = (usb_class_t) (p_cfg->type & USB_VALUE_7FH);I'd expect this USB_VALUE_7FH to be readded when requesting the active class.