7 years, 3 months ago.

FRDM-KL46z, Windows 10 and Fail.txt

Hello FRDM-KL46z community!

Apparently, there has been a problem plaguing the KL26Z and KL46Z mbed environment and it is associated with Windows 10 (and based on other notes I've read, also Windows 8.1).

I began to suffer from this problem about a year ago, and at that time I came to a standstill with resolution. I decided then to take a wait-and-see approach, hoping that the problem would resolve itself in the bye and bye.

I was wrong. Here I am again with the same set of issues, and no closer to finding a solution. So before I throw up my hands and say "AARGH!" as Snoopy would do, I'll try my luck with asking the question.

1. The Fail.txt problem is because of having a PE micro bootloader that isn't 1.11. Nope! Stills happens with my setup. Windows 10 and KL46Z. Upgraded from 1.09 to 1.11 (on a windows 7 machine).

2. The Fail.txt problem is because of having a bad PE Micro debug image. Nope! Fails the same with a 1.14 and 1.18 debugger.

3. The Fail.txt problem is because of an old MBED driver. Nope! Most recent downloaded and installed. Worked for about 20 minutes and then failed. Now it won't work. I was able to successfully run 'blinky' on the board until the first fail.txt happened and then poof, nothing works now. (the fail.txt says "TIMEOUT").

I can believe it is an interaction with Windows 10, but whatever that interaction may be is beyond me.

I'm hoping there is someone out there who has *really* solved this problem, or has used a solution that actually worked (longer than 20 minutes.)

Please help!

Otter2016

Moved comment to bottom of thread...

posted by Fred Kellerman 19 Sep 2017

3 Answers

5 years, 8 months ago.

Hello,

When I plug the USB cable for the FRDM-KW019032 board into a windows 10 computer a file pops up in the MBED folder for the board that says 'Fail'. When I open the Fail.txt all it says is Timeout. Is there a way to get rid of this error? Is this a critical error to the board functioning properly? I ultimately want to get this board to function as a receiver for an FXTH870 development board. https://play.google.com/store/apps/details?id=com.CRE8.LudoChat

7 years, 3 months ago.

Hi Rick,

Try to disable Windows Storage Services. Don't know about KL46 but the K64F latest mbed firmware fixes the issue (it's not Windows fault). So the strategy for the K64F is to disable WSS, upgrade the firmware and then it should be OK to have WSS on again, or just leave WSS off. Google how to disable WSS.

Best regards

Hi Fred, I'm on a Windows 10 client and there are no drives allocated for Storage Spaces. I've gone through the services and I don't see a specific service for Windows Storage Spaces. BTW. officially, WSS means Windows Sharepoint Services so I had a struggle to sort that out. Google has information on how to add and reove drives (once they are allocated) but it doesn't offer much help on the service. Can you think of any other angles I might try? Rich

posted by Rick Knowles 19 Sep 2017

Hi Rick, Storage Services under computer management is related to storage spaces, sorry for the confusion. Try disabling that and try again. The storage services are trying to index the NXP boards and messing them up.

Or if you have a Windows 7 PC use that to upgrade the board to the latest set of booloader and daplink firmware and that is supposed to fix it to work with Win 10.

Here is an article related to all of this but it doesn't talk about the storage services.

https://mcuoneclipse.com/2016/08/01/bricking_and_recovering_opensda_boards_in_windows_8_and_10/

posted by Fred Kellerman 19 Sep 2017

Fred, Thanks for the followup. In the services panel I disabled "storage services" which allowed me to load the blinky. That ran for about 5 minutes and then failed. As I'd mentioned in my first post, I had already loaded updated OpenSDA bootloader (1.11) and the Debug SDA (1.18) using a Windows 7 computer. I also loaded an updated version of the MBED firmware on the W7 machine too.

I read the mcuoneclipse video/note and at one point followed those directions too but to no avail. It is wierd because once the 'fail' occurs it seems to corrupt the loaded executable image which doesn't work after the fail occurs.

After all this, I'm still clueless as to what the contributing factors really are. I have a second KL46z which does the same thing and a KL26z that ikewise fails. >sigh<

Rick

posted by Rick Knowles 19 Sep 2017

Hello again Fred, Just to continue the thread here so there are no dangling issues. I've upgraded my laptop to Windows 10 Professional which allowed me to access 'gpedit.msc'. I followed the steps provided by your link and I believe the group policy is right according to the link. I pulled down the blinky and had it running, but after 5 minutes it stopped and the mbed 'Fail.txt' reappears. PE Micro's site says everything is copacetic, but Windows 10 is just writing something that clobbers the image. If I take the failing KL46z and plug it into the Ubuntu system it works just fine. There is just some sort of Windows interaction that fouls up the mbed image. At this point I'm throwing in the towel. Since I have an ubuntu system that I can do my development work on I guess that will be about as good as it gets. Rick

posted by Rick Knowles 19 Sep 2017

Hi Rick, Like I mentioned I'm only really familiar with K64F which has similar problem. I'd make sure I'd update all firmware pieces (bootloader, debug and user) with windows 7 each time you get a fail. There was mention of disabling system volume information as well and for some that solved their problem. I don't know, maybe it's not fixed for your part numbers yet or Blinky brings additional problems somehow.

https://superuser.com/questions/1199823/how-to-prevent-creation-of-system-volume-information-folder-in-windows-10-for

Note the extra step for windows 10 to disable search indexing as well.

Best regards

posted by Fred Kellerman 19 Sep 2017

One more maybe helpful tidbit (again I don't have your board but I use the K64F Freedom and it has similar issues as well with Win 8/10). So I was speaking with ARM today about the K64F and mentioned your post and they think you have an older version of the interfaces firmware piece.

Best of luck in getting this fixed, hope this helps!

posted by Fred Kellerman 19 Sep 2017
5 years, 8 months ago.

The problem STILL is present in 2019 and there appears to be no solution. It appears to be a problem with the Nucleo itself as

1) it still happens when I move the Nucleo to another computer 2) it still happens after a re-flash the newest ST-Link firmware 3) on a Mac

I think the solution is to give up trying to use the mass storage feature and use an ST-Link dongle.

Oh, sometimes it "just works" once or twice then become broken again.

I can confirm. I just got mine out of the box and it hasn't worked once. After over an hour of Googling, I couldn't find a solution that worked for my machine.

posted by Bryan Redd 02 May 2019