Overview

The Microchip PIC32CX-BZ6 Series Device Family Pack (DFP) is a CMSIS-Pack that:

• Enables compatible tools with device support.
• Contains support files for the MPLAB XC32 Compiler.
• Contains support files for the GCC compiler.
• Contains support files for the Arm Compiler for Embedded.
• Contains support files for the IAR Embedded Development Tools.
• Contains System View Description (SVD) descriptions of the peripherals.
• Flash algorithms for the on-chip flash memory.

Related packs

    - pack: ARM::CMSIS

Devices

PIC32CX2051BZ62132

The PIC32CX2051BZ62132 is a highly integrated, wireless MCU SoC offering exceptional scalability, flexible connectivity (both wireless and wired) and versatile peripherals for industrial, automotive and IoT applications.Supports complex applications and future proofs designs with 2 MB Flash and 512 KB RAMAccelerates time to market with Bluetooth® LE, Thread®, Matter and proprietary wireless connectivityEnhances user experience and control with advanced peripherals including touch, graphics, CAN FD, Ethernet and USBProtects your application and IP with built-in secure boot and hardware-based security engineSimplifies development with proven chip-down reference designs, regulatory-certified modules and support for MPLAB® and Zephyr® development environments

Documentation:

• Highly Integrated Wireless MCU with CAN FD, Ethernet, USB, Motor Control, Graphics, Touch and Enhanced Security
• Highly Integrated Wireless MCU with CAN FD, Ethernet, USB, Motor Control, Graphics, Touch and Enhanced Security

Application Notes:

• Getting Started With Graphics on the PIC32CX BZ6 Wireless MCU

Additional Documents:

• PIC32CX-BZ6 Family Silicon Errata
• PIC32CX-BZ6 Programming Specification
• Bluetooth Product Comparison Chart

PIC32CX2051BZ66048

The PIC32CX2051BZ62132 is a highly integrated, wireless MCU SoC offering exceptional scalability, flexible connectivity (both wireless and wired) and versatile peripherals for industrial, automotive and IoT applications.Supports complex applications and future proofs designs with 2 MB Flash and 512 KB RAMAccelerates time to market with Bluetooth® LE, Thread®, Matter and proprietary wireless connectivityEnhances user experience and control with advanced peripherals including touch, graphics and CAN FDProtects your application and IP with built-in secure boot and hardware-based security engineSimplifies development with proven chip-down reference designs, regulatory-certified modules and support for MPLAB® and Zephyr® development environments

Documentation:

• Highly Integrated Wireless MCU with CAN FD, Ethernet, USB, Motor Control, Graphics, Touch and Enhanced Security
• Highly Integrated Wireless MCU with CAN FD, Ethernet, USB, Motor Control, Graphics, Touch and Enhanced Security

Application Notes:

• Getting Started With Graphics on the PIC32CX BZ6 Wireless MCU

Additional Documents:

• PIC32CX-BZ6 Family Silicon Errata
• Bluetooth Product Comparison Chart
• PIC32CX-BZ6 Programming Specification

PIC32WM_BZ6204

PIC32WM_BZ6602

MISRA Compliance Deviations List

MISRA-C:2023

Deviation ID: MFWCG-40

• Rule 5.5: Identifiers shall be distinct from macro names.
• Use case: Identifiers corresponding to register names.

Example:

```C typedef union { struct { uint32_t GPIO:29; uint32_t :3; } vec; uint32_t reg; } ECIA_SRC8_Type;

#define GPIO (0x40081000) ```

• Reason: Access to hardware.

The macros expand into the same identifiers, which allow users to detect for the presence of specific registers during preprocessing.

• Scope: Device headers for the DEC15xx and MEC15xx family (<device-name>.h).

Deviation ID: MFWCG-42

• Rule 20.9: All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation.
• Use case: Use of compiler builtin macros.

Example:

C #ifdef (__ARM_FP == 14) || (__ARM_FP == 4) fpu_enable(); #endif

• Reason: Access to hardware.

Headers may rely on builtin macros from the compiler and are written under the assumption that if the macro is not defined, its value is zero.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-43

• Rule 21.1: #define and #undef shall not be used on a reserved identifier or reserved macro name.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C #define __IO volatile

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-44

• Rule 21.2: A reserved identifier or reserved macro name shall not be declared.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C extern const VECTOR_TABLE_Type __VECTOR_TABLE;

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

MISRA-C:2025

Deviation ID: MFWCG-44

• Rule 5.10: A reserved identifier or reserved macro name shall not be declared.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C extern const VECTOR_TABLE_Type __VECTOR_TABLE;

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

Deviation ID: None

• Rule 11.4: A conversion shall not be performed between a pointer to object and an arithmetic type.
• Use case: Setting special registers from linker-generated symbols.

Example:

C pSrc = (uint32_t *) & __svectors; SCB->VTOR = ((uint32_t) pSrc & SCB_VTOR_TBLOFF_Msk);

• Reason: Access to hardware.

Some hardware registers do not have a pointer type but hold an address.

• Scope: Device startup code (startup_<name>.c)

Deviation ID: MFWCG-42

• Rule 20.9: All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation.
• Use case: Use of compiler builtin macros.

Example:

C #ifdef (__ARM_FP == 14) || (__ARM_FP == 4) fpu_enable(); #endif

• Reason: Access to hardware.

Headers may rely on builtin macros from the compiler and are written under the assumption that if the macro is not defined, its value is zero.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-43

• Rule 20.15: #define and #undef shall not be used on a reserved identifier or reserved macro name.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C #define __IO volatile

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

MISRA Compliance Deviations List

MISRA-C:2023

Deviation ID: MFWCG-40

• Rule 5.5: Identifiers shall be distinct from macro names.
• Use case: Identifiers corresponding to register names.

Example:

```C #define WDTCON WDTCON extern volatile uint32_t WDTCON attribute((section("sfrs"), address(0xBF800000)));

#if defined(WDTCON) // Code that accesses WDTCON register #endif ```

• Reason: Access to hardware.

The macros expand into the same identifiers, which allow users to detect for the presence of specific registers during preprocessing.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-41

• Rule 5.8: Identifiers that define objects or functions with external linkage shall be unique.
• Use case: Unions of bitfield structures that represent the implemented and semantic bits of the register.

Example:

C extern volatile uint32_t SYSKEY __attribute__((section("sfrs"), address(0xBF800030))); typedef struct { uint32_t SYSKEY:32; } __SYSKEYbits_t;

• Reason: Access to hardware.

The names assigned are the same as those in the device data sheet. These are in direct correspondence to simplify code comprehension.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-42

• Rule 20.9: All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation.
• Use case: Use of compiler builtin macros.

Example:

C #if defined(__PIC32_HAS_MICROMIPS) // Conditional code for micromips #endif

• Reason: Access to hardware.

Headers may rely on builtin macros from the compiler and are written under the assumption that if the macro is not defined, its value is zero.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-43

• Rule 21.1: #define and #undef shall not be used on a reserved identifier or reserved macro name.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C #define _ICDSTAT _ICDSTAT

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-44

• Rule 21.2: A reserved identifier or reserved macro name shall not be declared.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C extern volatile uint32_t _ICDSTAT __attribute__((section("sfrs"), address(0xBF801010)));

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

MISRA-C:2025

Deviation ID: MFWCG-40

• Rule 5.5: Identifiers shall be distinct from macro names.
• Use case: Identifiers corresponding to register names.

Example:

```C #define WDTCON WDTCON extern volatile uint32_t WDTCON attribute((section("sfrs"), address(0xBF800000)));

#if defined(WDTCON) // Code that accesses WDTCON register #endif ```

• Reason: Access to hardware.

The macros expand into the same identifiers, which allow users to detect for the presence of specific registers during preprocessing.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-41

• Rule 5.8: Identifiers that define objects or functions with external linkage shall be unique.
• Use case: Unions of bitfield structures that represent the implemented and semantic bits of the register.

Example:

C extern volatile uint32_t SYSKEY __attribute__((section("sfrs"), address(0xBF800030))); typedef struct { uint32_t SYSKEY:32; } __SYSKEYbits_t;

• Reason: Access to hardware.

The names assigned are the same as those in the device data sheet. These are in direct correspondence to simplify code comprehension.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-44

• Rule 5.10: A reserved identifier or reserved macro name shall not be declared.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C extern volatile uint32_t _ICDSTAT __attribute__((section("sfrs"), address(0xBF801010)));

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

Deviation ID: MFWCG-43

• Rule 20.15: #define and #undef shall not be used on a reserved identifier or reserved macro name.
• Use case: Reserved names, beginning with _ followed by a capital letter or __ followed by a lower-case are within the compiler's namespace.

Example:

C #define _ICDSTAT _ICDSTAT

• Reason: Access to hardware; Code Quality (Usability: Accessibility).

Within these headers originate many reserved names that are within the compiler's namespace.

• Scope: All device headers (<device-name>.h).

Support

For support questions, contact Microchip Support through https://www.microchip.com/en-us/support.