CubeProgrammer, erm...

[waclawek.jan]

Control is confusing. What's wrong with normal menus and tabs? And the worst idea, Save File is a pulldown of the Read button. Took me some time to discover.

Please, ditch the "modern feel and look" (and this of course goes also for the web, the forum, the appnotes, etc.) and rework it into a decent-looking conservative user interface. Inventing yet another fancy user interface is counterproductive, and gets into way of serious work. We are engineers, not some novelty-seeking youth.

Another one. When I perform the Save, the following window appears:

 [

Okay, no picture, courtesy of force programmers who can't fix this bug in other way than to display a warning. Oh, much like this case!. And I've forgotten to insert it from the store - and it's not stored there, which is again something new.

I am not going to fire up CubeProgrammer just to take the screenshot again. Feel free to do it yourself; it's 100% reproducible - try to save a file which already exists. Basically, the window screenshot of which I was supposed to put here says, "Warning, this file already exists and *will be* overwritten".

]

but it does so only AFTER the original file has been overwritten! Argh. This can't be called other than a serious error.

More. The idea of mapping the external memories into a continguous memory space is principially wrecked. What if I have several external memories which are multiplexed onto the same ARM address space, and I do have appropriately written loaders? And what if I have several memories connected through interfaces, which don't map to ARM address space at all, and their total volume is >4GB?

One + : the detailed level 3 logging helped me indeed in debugging the external memory interface. Thanks.

Jan Waclawek

[waclawek.jan]

With programming external memory (sFLASH), if I set log verbosity to 3 and tick Verify programming, CubeProgrammer freezes after programming and starting the verification . After killing the application and restarting it, it can't connect to STLink, STLink has to be reset.

JW

[Tesla DeLorean]

>>And the worst idea, Save File is a pulldown of the Read button. Took me some time to discover.

The first iteration you couldn't even save anything..

>>CubeProgrammer freezes after programming and starting the verification .

Are we sure it is not just crashing inside your loader code?

I'm not convinced this is the method to program >4GB onto a product. Surely some payload device would be a better route (eMMC dongle), probably a lot to stream over an ethernet cable.

[Tesla DeLorean]

The UI is truly awful. Perhaps the CLI would work better?

Before we could save in the GUI tool, the CLI did provide a means to read/save content.

How many hours to you have to spare to send 4GB+ of stuff over the JTAG/SWD?

[waclawek.jan]

> >>CubeProgrammer freezes after programming and starting the verification .

> Are we sure it is not just crashing inside your loader code?

Actually, after some time (like 5-10 minutes or so), it unfreezes with something like "0x413 is not responding" (0x413 is the ID of the target '407). The log contains the whole history of reads of the whole external memory, and given SPI bus activity the whole memory was read (the LA can't capture all of it but I'm judging from the length of it, which I see on LEDs) . Reading it through the read facility goes OK. I guess during verify there's some buffer overflow on the way through the USB and layers in Windows/Javas. Low importance.

> I'm not convinced this is the method to program >4GB onto a product.

I might not need to program >4GB at once; I need to have the option to have the memories around and program a portion of them when I need fit, though. I complain about the incorrect thinking rather than implementation here.

Wouldn't be unable to resolve the loader, I would go other ways. This is just more convenient once working.

JW

[T J]

Visual studio is very good..

but I guess it is what you are use to...

personally looking at using an SDcard to transfer large files into external flash

[Tesla DeLorean]

Not sure this is a tool-chain thing, STM32 Cube Programmer is really the "production programmer".

Problem with SD Cards is that they will tend to get chewed up in a production environment, or left in sockets.

If the primary board doesn't have an SD Card socket, one could use a dongle to hold one, or an eMMC, or introduce the pins via a bed-of-nails. The dongles being considered somewhat sacrificial as they would take the brunt of the reuse.

One of the old boards I worked on used a ROM card, you plugged it in, and it also changed the decode mapping of the host processor so it would boot from the card rather than the blank flash devices on the host board. Code was built into the primary app to recognize this, and then copy itself from the very large EPROMs to the FLASH, so the "Golden ROMs" basically 100% copied themselves, and there was one production image.

People also stream via Ethernet, with a server looping the image continuously in broadcast mode. A small loader on the devices would then start where ever in the loop it was, and finish when it had gone full circle.