M2M Q24

[awneil]

@Flex

“no compression” and 256k memory type.

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

[awneil]

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

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

[victorjd]

@awneil

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

Yes

@awneil

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

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

[awneil]

@victorjd

Toolchain automatically switch between (wzpacker + genbin) and (addchk + genbin) as you change “WPB format” option at “Build settings”

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

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

[daav]

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).

[daav]

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.

[awneil]

@daav

Mmmm, seems that -C option for wzpacker is not enough

No, it isn’t.

However, turning off the ZIP compression restores a correct download.

I didn’t see an option to do that:

@wzpacker -help

WzPacker v1.3.5 (c) Wavecom 2002-2008

Compresses a file for DWLWin, OTA and XMODEM downloads.

Usage:

WzPacker [compression options] <file>
                Compresses filename.bin into filename.wpb

WzPacker [compression options] <filein> <fileout>
                Compresses <filein> into <fileout>


Available compression options:
-b, --base          Sets the base address in memory of the binary
                    (0 by default)
-t, --target        Sets the target of the binary
                    Known targets:
                    onec12 : for OneC 1.2 basebands
                    onec13 : for OneC 1.3 basebands
                    gps    : for Wismo Q2501's GPS chip
                    openat : for secured Open AT application download
                    any    : do not mind (default)
-c, --code          Sets the target of the binary using its numeric code
-f, --nofooter      Do not create a footer with the date and size of the file
                    (should be set if the file is not a GSM stack)
-C, --oldcompat     Set the version number to 1.01 when possible
                    so that the binary can be downloaded by an old DwlWin
                    (otherwise, DwlWin 3.3 or later is needed)
-z, --lzma          Higher compression ratios (for Q26 platforms only).
-T, --thumb         Activate ARM/Thumb encoding filter.
-s, --sign          Sign the binary using an RSA (512, 1024 or 2048 bits) private key

-h, --help          Displays this message

You said you found a workaround be calling addchk.py between wzpacker and genbin…

I did

I guess you’ve done this manually

Correct!

can you post here the console log, including the parameters you used?

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…

[daav]

@awneil

However, turning off the ZIP compression restores a correct download.

I didn’t see an option to do that

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)

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

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…

[awneil]

@daav

Project properties > Open AT Application > Build Settings, and change “WPB Format” from “ZIP format” to “No compression”.
This will produce a functionnal .dwl file

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

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

Ok, it should download correctly after that, but can you confirm the application is correctly running after the download?

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

Sounds strange for me that the bootloader unpacks correctly the file when it is created without the -b option…

Where would you expect that option?

[daav]

@awneil

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.

[awneil]

@daav

Last tip: did you think about just upgrade your bootloader to V02.1F?

Can that be done remotely?

if for any reason you can’t upgrade the bootloader, please let me know.

It would have to be possible remotely via DOTA…

[awneil]

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

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

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

[daav]

@awneil

Can that be done remotely?
It would have to be possible remotely via DOTA…

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

@awneil

It seems I was mistaken - it doesn’t work with or without the -b option
The download competes witout complaint, but the application is not recognised

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…

[awneil]

@daav

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?

[daav]

@awneil

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?