EM35x

As the interfaces and pinouts and protocols are quite different between
the EM2xx chipset (which uses the 16-bit XAP2b architecture and the proprietary SIF debug/programming protocol from CCL) and the EM3xx chipset (which uses the 32-bit ARM Cortex-M3 architecture and the more standardized JTAG and SerialWire debug/programming protocols), there’s no compatibility (in either direction) between the development tools from one
platform and the devices/chips from the other platform.

Currently, the ISA3 (EM3xx-era ISA) is the only device that can be used to program
EM3xx chips, and the ISA [

When performing RF compliance testing on your Ember-enabled design, some test houses may require information about the analog frequencies inherent in the design, so that they can check for the presence of harmonics or any other unwanted noise products of these oscillating signals.

To aid customers in supplying this information to test houses, a listing of the frequencies used by each chipset (or typical components from its corresponding reference designs) is shown below, along with a brief description of where the signal originates or what its purpose is.

Sure, you can get a simple reset reason code from halGetResetString(), and with the EM35x HAL you can even get some more verbose description of that reset type through halGetExtendedResetString(), but these only tell you what general variety of reset you experienced.

For certain kinds of resets, it may be useful to just know the approximate program counter (PC) address where the code ended up just prior to the crash. In those cases, the PCDiagnostics routines can be used to pinpoint the last known PC, similar to how this works on Ember’s EM250 platform.