Can not debug MIMXRT1050-EVK Rev. A4 in OSX

Hello I am using MCUXpresso IDE, version v10.1.0 [Build 589] [2017-11-14] with an MIMXRT1050-EVK SDK, version 2.3.0 (2017-11-16). I was previously using a Rev. A3 of the MIMXRT1050-EVK and was able to program and debug via the OpenSDA interface under both Linux and OSX. Our new A4 boards do not enumerate under Linux and although they enumerate under OSX, they can not be debugged under OSX. When a debug is attempted the following error occurs:

Hello. The mass erase procedure had some effect but enumeration under OSX is unreliable as is programming and debugging. There is still no enumeration under Linux at all. Please see the following programming errors, thanks.

When I say fails to enumerate I mean USB fails to enumerate, no RT1050 drive shows up and dmesg shows no USB activity whatsoever. And because USB doesn't enumerate, MCUXpresso can't see the probe at all. I have tried Ubuntu 14.x (a VM) and 16.x (a PC). The 16.x behavior is somewhat better in that it occasionally enumerates USB.

The DETAILS.TXT file is long, sordid tale. If you go to to the OpenSDA debug adapter site you can download two firmware files, k20dx_mimxrt1050_evk_qspi_if_crc.bin and k20dx_mimxrt1050_evk_hyper_if_crc.bin. Bizarrely, it is k20dx_mimxrt1050_evk_qspi_if_crc.bin that lets me program HyperFlash on the Rev. A3 boards (?!) and I have confirmed this repeatedly. Surely the files are mislabeled, if not then please carefully explain this naming convention. Anyway, here is what the DETAILS.TXT contain for each FW/Rev variant.

Regarding your questions 3 and 4. Yes, I have done all of this over and over and have been careful to follow each step, DIP switches and all. As I mentioned, the flash erasing process worked and had some positive effect but the A4 probes are still unstable, giving the messages I pasted in the previous response.

The behavioral differences in the A4 boards are not subtle and the problems exist across Linux, OSX and Windows. There is clearly something different about them. The only HW change in the schematic is "Update BOM only to change CSI related serial 0ohm resistor from DNP to mount, mount R352 and DNP R353". On a whim, I've tried reverting this change to no avail.

2 - they still contain problematic code within the Hyperflash, so this needs erasing before a successful debug operation can be performed.

3 - we have not been able to duplicate any enumeration issues on Mac or Linux when debugging and powering the board via the OpenSDA debug connection.

4 - using an SDK downloaded from Welcome | MCUXpresso SDK Builder we have not seen any debug problems using either RAM based or the single xip examples. Similarly, projects created via the new project wizard (which are also flash based and xip) also program and run without issue. (from Mac, Linux (16.04 real hardware) and Windows). Note: we have seen issues with pre-release versions of the SDK, so please be sure you are using a fresh download.

With regard to the difference variants of OpenSDA binaries, I would expect the Hyperflash variant to support programming of the Hyperflash via drag and drop, and similarly the QSPI variant will support the QSPI via drag and drop (but this would obviously only be applicable for boards modified to use the onboard QSP and has not been tried by the IDE team). WRT generic debug, I would not expect there to be a difference.

Obviously, this doesn't provide a solution to the problems you are seeing - so please can you tell us:

Assuming you can get a board to enumerate: If the hyperflash is erased and the board is power cycled... does a RAM based project debug. Since flash programming operations are by their nature, RAM applications, and you report the flash programming succeed (in earlier logs) I would expect these to work.

If you more than one of the Rev 4 boards, and if so, is the behaviour identical between these boards?

Have you made any attempt to re-program the OpenSDA firmware on these Rev4 boards?

Thanks for the reply, this helps. I am still having enumeration issues after flash bulk erase but I have found a strange way of bringing the boards back to life. I bring them up first in maintenance mode, where they do enumerate and after that I can re-plug and they enumerate normally. I have no idea why this would work. I have been using OpenSDA with rev. A3 and A4 boards because I can not write flash via JLINK.