M2M Q24

in vs2003… i prefer eclipse… if Icould use VS2010 :laughing:

Well… but compiler is the same, things like this? (updates… etc)

Using a Fastrack M1306B; 657_09gg.Q2406B 1954500 102706 18:44

I’ve imported & installed the packages, and my App builds OK - but it won’t download. :angry:

The only two options available in Properties > Open AT Application > Build Settings > WPB Format are:

  • ZIP Format;
  • No Compression.

It makes no difference which one I select - the download always fails with *** ERROR IN FILE ***

Bootloader version is:

+WDWL: V02.1B

What’s wrong :question:

Never worked with old Q24. But your can check if your .dwl file really not compressed - little bigger than .bin.

If no more suggestions, and if you know how SiWi tools convert BIN to DWL (python script + genbin.exe), your can check file for errors.

Try to download a dwl.dwl file from your firmware catalog. Eg if you use package with 6.57g download dwl.dwl for 6.57g.
Also Q24 is ok to use compression if provided with valid downloader. But we do not even try to update Q2406 which are way too old.

I don’t deal with Q24 anymore, but what I remember from the days was “no compression” and 256k memory type. Btw do clean the project and full rebuild after you change that stuff, just to make sure it actually does anything.

The only available “Memory Type” in the list is ‘X’ - is that right?

OK - the answer seems to be:

  1. The -C option is needed on wzpacker (backwards compatibility), and
  2. The addchk.py Python script has to be run on the result

So the next question is: how do I set this up to happen as part of the build :question:

Presumably, I need to add a new “builder”…?

Yes

Not exactly. Toolchain automatically switch between (wzpacker + genbin) and (addchk + genbin) as you change “WPB format” option at “Build settings” and apply changes (look at project properties → C/C++ Build → Settings, genbin call options also different for this two modes).

For my Q24 projects after .BIN generation (No compression mode) :
project.BIN => addchk.py => project.BINC
project.BINC => genbin -adr 0x00210000 => project.DWL

Indeed - and that does not work! (not for me, any how)

It needs to be wcpacker -C followed by addchk followed by genbin!

You can modify the wzpacker command line in your project options (cf attached snapshot)


Please let me know if it’s enough (we will add the option as a checkbox in the “Binary packer options” category).

Mmmm, seems that -C option for wzpacker is not enough (just made the test with 6.65f & V02.1D bootloader: unable to download…)
Developer Studio seems to be compatible only with V02.1F bootloader (which has came with 6.57g).
However, turning off the ZIP compression restores a correct download.

You said you found a workaround be calling addchk.py between wzpacker and genbin…
I guess you’ve done this manually: can you post here the console log, including the parameters you used?
I gave a try but wasn’t able to download a compressed binary.
As soon as I get the correct procedure, I’ll see how to include it in the studio, and also provide a workaround by adding a post-build step.

No, it isn’t.

I didn’t see an option to do that:

I did

Correct!

wzpacker  -C <project>.bin <project>.wpb
python.exe -E addchk.py <project>.wpb <project>.wpbc
genbin -bin <project>.wpbc -dwl <project>.dwl -adr 0x00210000 -verbose

I didn’t have much success making that into a post-build step… :cry:

It’s not a wzpacker option, but a project one: go to Project properties > Open AT Application > Build Settings, and change “WPB Format” from “ZIP format” to “No compression”.
This will produce a functionnal .dwl file, but obviously bigger than the compressed version (almost same size than .bin file)

Ok, it should download correctly after that, but can you confirm the application is correctly running after the download? Sounds strange for me that the bootloader unpacks correctly the file when it is created without the -b option…

Yes, I saw that - but it didn’t work for me!

As noted earlier, neither packed nor unpacked worked for me!

I’m pretty sure it did - have to get back to you tomorrow on that…

Where would you expect that option?

This is an option to be provided to wzpacker, in order to specify the link address of the application (as it is provided to genbin); you’ll see how it is used when looking at the Developer Studio build console log.

I asked you if your application was correctly running, because when I made almost the same test (but with the -b option for wzpacker), the download was OK, but then the application was not started (even not detected by AT+WOPEN=2 command)
I’ll make the test without the option.

Last tip: did you think about just upgrade your bootloader to V02.1F? (the one packaged with FW 6.57g)
This will solve the download issue (since actually Developer Studio produces dwls which are not compatible with older versions).
Initially we considered that this is acceptable since you can upgrade the bootloader to a compatible version.
But if for any reason you can’t upgrade the bootloader, please let me know and we’ll have a thought on how to fix this.

Can that be done remotely?

It would have to be possible remotely via DOTA…

It seems I was mistaken - it doesn’t work with or without the -b option :cry:

The download competes witout complaint, but the application is not recognised:

at+wopen=2
+WOPEN: 2,“AT v03.12”

:cry:

Yes it can; you should do it in two steps: firstly upgrade dwl.dwl, and then upgrade your app.

Mmm… I’ll have a look on why old Open AT IDE was able to produce .dwls compatible with old bootloaders, and why Developer Studio isn’t…

Any update on this?

Thanks for the reminder, and sorry to have forgotten posting here the investigation results…
Actually, it seems that even former Open AT IDE V1 wasn’t able to generate compressed dwl that are compatible with V02.1D bootloader.
But what I have observed is that in both cases (Open AT IDE and DS), when you use an uncompressed dwl, V02.1D bootloader accepts it.
Regarding the thread history, it seems that on your side, even an uncompressed dwl can’t be downloaded by V02.1D bootloader. Seems to be the heart of the matter, since I can’t reproduce this behavior… Can you confirm?