Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sw-nw2s

Pages: [1]
1
Thanks for continuing the discussion. I've been assembling hardware, getting caught up with orders and will be back to this shortly. Everything has been a big help so far. I appreciate all the feedback.

2
Thanks for the heads up. Yeah, I was planning on just mimicking MCUBootUtility using command line tools. Worst case, I guess I will just have to use a Windows box for production flashing. I just need to get a generic app migrated to be loadable by utasker boot loader so I can continue to develop using the projects already in place in my os x world... Depending on how long I bang my head there tho, that may have to change as well. Have to take a couple of days to catch up on orders, do some soldering and will be back at it.

Scott

3
I see... one thing I missed was I was watching the "Pearl Izumi" video... Didn't see there was another one for setting up ITC builds to run. Looks like you mentioned in the video that the code should start at 0x300 and I can confirm that your demo app output *.map file indicates .text starts at 0x300... so for it to work, that's what I'm going to need to work on. (and some things with the vector table it looks like)

Weird tho that the bootloader doesn't load my app with the auth and magic number set correctly. I guess it's also validating other stuff before it will burn it to flash - is that documented anywhere?

s

4
Thanks. I have intermittent access to a windows machine, so I can test some things out - again as a control so I can try to adapt to my normal workflow.

So for now I am able to flash the locally compiled boot loader to the 1060 EVK. Great news. I am also able to download your demo 1060 app and run that using the bootloader... and switch between the application and the bootloader at will. Again progress!

The MCUBootUtility you reference in your docs and videos is just a wrapper around sdphost and blhost just like the NXP provided secure provisioning tools, so I should be able to adapt that to os x since those command line tools are cross platform. I'll work on documenting that and provide any details if anyone is interested for posterity here.

The next little bit of complication is that I am trying to upload a *.bin which has been compiled independently of the utasker app framework. You have a video here which references a generate.bat file which I don't seem to see anywhere, but it's readable in the video, so I can see that the part I'm interested  in seems to be just one command which is in the other specific generate.bat files in your application folders...

https://www.youtube.com/watch?v=5iT7KP691ls&ab_channel=mjbcswitzerland

Roughly translated:

uTaskerConvert.exe blinky.bin blinky-upload.bin -0x1234 -a748b6531124

however, when I copy this new bin file over to UPLOAD_FOLDER, it does not "consume" it... it just sits there unlike when I upload the sample app from website and/or the built sample utasker application, it reboots itself as soon as it copies and begins running immediately.

I assume I'm missing something, but I'm not sure. Still trying to work through that. I verified that the auth value and magic number are the same as in the build of the bootloader... Must be something else the loader is verifying.









5

I am just getting started with the i.MX bootloader. I have successfully built the default bootloader project using MCUxpresso.

I have also successfully uploaded both the default build and the serial bootloader demo from the RT1060 information page to the MIMXRT1060-EVK using the embedded DAPlink MSD interface.

So far so good. My goal however is to use the EA OEM which obviously doesn't have the OpenSDA DAPlink. I'm trying to get the EVK running as a control and then move to the EA OEM board once I know it's running on the EVK.

That means that I need to use the NXP Secure Provisioning Tool as I'm on OS X and the python open source tool listed in the utasker docs requires Windows.

The Secure Provisioning Tool does a few things, but I'm trying to just use it in it's most basic form (no encryption, no signing). My understanding is that I have two options.

1. Add a DCD header to the *.bin file prior to uploading so that it's a "bootable" image.
2. Don't add the DCD header in case you already have compiled in the proper structs at the beginning of the binary data.

If you choose to add the DCD header, you need to add the start address which seems to default to 0x60000000. I'm not sure if that's correct or not based on the utasker complete loader binary (BM, Fallback, and Bootloader all in one bin)

So I'm not sure if the utasker binary that I'm uploading includes the DCD block and if it does not, what I should be setting the start address to.

Ive attached a screenshot of the image build log output and the blank screen with the options populated as built. When I upload, the indications are that it uploads successfully via USB-HID.

The problem is that neither the default build nor the downloaded example bin file will boot when uploaded using the secure provisioning tool even though the both work with the DAP link. I'm sure I'm missing something here.

Thanks,

Scott




Pages: [1]