Confusing code

[FZR1KG]

Here is the code I have so far traced the problem to.
I'm including my C call to the function as well:

prototype for function called
char EE2PROM_bE2Write(WORD, *CHAR, WORD, CHAR);
My call

ext_uchar = EE2PROM_bE2Write(uINT , & FlashData, 64, 40); //64 is the length of the block, 40 is the temperature.

-----------------------------------------------------------------------------
//EEPROM PSoC standard library routine

_EE2PROM_bE2Write::

CPU_F: equ 0 ; note, I'm using a 29466 so this should be 0xF7 unless I am mistaken

IF (CPU_F)
MOV A,reg(CPU_F)
PUSH A
ENDIF

MOV A,>EE2PROM_START_BLOCK
PUSH A
MOVE A, <EE2PROM_START_BLOCK
PUSH A
LJMP bE2Write

;note the return will be done via a RETI instruction to preserve the original paging mode and flag status

This is where the code jumps to, as found in the .lst file.

bE2Write::
MOV X,SP
SWAP A,X
CMP A,234 ; is there stack space free to do the write?
JC .CONTINUE_WRITE ; plenty of stack space to do a write so continue
MOV A,254 ; not enough stack space so return
ADD SP,A ;SP = SP -2
RETI ;Return from Interrupt, pops off Flag first then low address then high address of the PC register
.CONTINUE_WRITE

Now the code crashes after the library routine is called, in the bE2Write function call.
I only traced the very first part, if the SP is too large it returns with an error, or is meant to.

The strange part is, it works in the SMM and I can't see why, but, I've had the EEPROM writes crash my system if the stack was too small rather than just returning so I think this is a long standing bug.

My routine places data on the stack then calls the EE2PROM routine. It pushes 7 bytes of parameters then two for the return address, total 9 bytes.
The CPU_F is equated to 0 so it doesn't push another byte in the library code, but it pushes two more that are the starting address of the EE2PROM I have defined, which is not executable code, it is the start of data.

The code then does a jump to bE2Write, not a call and returns using a RETI instruction.
Before it returns, it subtracts the SP register by 2.
Then the RETI is executed and the following happens:
The stack will now pop off the lower byte of the return address of my code and put it into the flag register.
Then it will pop off the higher byte of the return address and put it into the low address of PC
Then it will pop the last parameter (the temperature) and put it in the high address of PC

That can't be right and explains why my code always crashed if the SP got too large instead of returning an error.

I haven't traced the code when the SP is ok to continue but I'm suspecting it too has issues.
I don't know where to find the source code for it and debugging via a list file is not easy.

Fun times...

[FZR1KG]

Case opened with Cypress.
It is looking to be more and more an inbuilt library issue than my code.

[Sigma_Orionis]

Good Luck

[cid]

I'm sorry...I believe you've mistaken us for someone who knows what the h3ll that means...

[FZR1KG]

I'm sorry...I believe you've mistaken us for someone who knows what the h3ll that means...

You're a qualified computer guy now CiD.
Do what you have studied to to. Fake it!

That's what education is, giving you the ability to make others believe you know what you are doing.
The problem's only start when you start believing your own hype. lol

[Sigma_Orionis]

Just to be clear you damned WTF stew brewing ape.

You (obviously) did the code in C.

While I've seen .lst files when I compiled stuff in other environments, never paid attention to them (which tells you how often I code )

So as usual, while I had a hunch that it would list the C to assembler translation code I had to goggle it (THAT's how I fake things cid ) to at least be sure.

So you're seeing the actual asm code (including the libraries) right?

[FZR1KG]

I see the asm code in the .lst file as that file is the final compiled code as converted to object code.

Here's my calling routine as seen in the list file

Code: Select all

_write_ee2prom:
  a                    --> X+0
  uINT                 --> X-5
3809: 10       PUSH  X
380A: 4F       MOV   X,SP
380B: 38 01    ADD   SP,1
(0119) char a;
(0120) RES_WDT = 0x38;
380D: 62 E3 38 MOV   REG[227],56
(0121) ext_uchar=(unsigned char)EE2PROM_bE2Write(uINT,&FlashData,64,40);   //block,address,len,temperature
3810: 10       PUSH  X
3811: 50 28    MOV   A,40
3813: 08       PUSH  A
3814: 50 00    MOV   A,0
3816: 08       PUSH  A
3817: 50 40    MOV   A,64
3819: 08       PUSH  A
381A: 50 00    MOV   A,0
381C: 08       PUSH  A
381D: 50 5C    MOV   A,92
381F: 08       PUSH  A
3820: 52 FB    MOV   A,[X-5]
3822: 08       PUSH  A
3823: 52 FC    MOV   A,[X-4]
3825: 08       PUSH  A
3826: 7C 0B 12 LCALL 0x0B12
3829: 38 F9    ADD   SP,249
382B: 20       POP   X
382C: 62 D0 00 MOV   REG[208],0
382F: 53 4C    MOV   [76],A
(0122)
(0123) Load_flash_error();
3831: 9F 37    CALL  _Load_flash_error
(0124) M8C_EnableGInt;
3833: 71 01    OR    F,1
(0125) }
3835: 38 FF    ADD   SP,255
3837: 20       POP   X
3838: 7F       RET   


I gave the wrong description earlier as the parameters are pushed on the stack in reverse order. Not that it makes much difference.
Though I did look at the library routine (it was the source code I posted originally) and it makes no sense.
it shows the equate for CPU_F as zero but pushes CPU_F on the stack anyway because it somehow gets CPU_F to be 247 (which is 0xF7) and correct.
Code shown below:

Code: Select all

0B12: 5D F7    MOV   A,REG[247]    (0215)    mov   A, reg[CPU_F]                           
0B14: 08       PUSH  A             (0216)    push  A
                                   (0217) ENDIF
0B15: 50 01    MOV   A,1           (0218)    mov   A, >EE2PROM_START_BLOCK          ; push the FirstBlockID - MSB
0B17: 08       PUSH  A             (0219)    push  A
0B18: 50 BC    MOV   A,188         (0220)    mov   A, <EE2PROM_START_BLOCK          ; push the FirstBlockID - LSB
0B1A: 08       PUSH  A             (0221)    push  A
0B1B: 7D 0C A3 LJMP  0x0CA3        (0222)    ljmp  bE2Write                                  ; jmp to E2PROMLIB


to read the list file, the numbers to the left of the colon are the address, the numbers to the right are the machine code instructions placed there for that instruction.
It shows the C code then the assembler code produced by it on a line by line basis.

Basically it is not working as per source code but is working to make the first part of the code correct.
Code that doesn't work as written, bugs me.

[Sigma_Orionis]

It should, cause if your hunch is right, UNLESS you've got access to the library source code, yer at the mercy of Cypress.

I've touched assembler only once or twice. But yeah, I now understand how to read the .lst file.

The first time I had this star trek game written in BASIC on my Trash-80, that had a small machine language routine to handle the screen, but since the code used hard addresses it overlapped with the basic interpreter that was loaded from disk (it worked fine when booting the machine with no OS and using the built-in ROM BASIC interpreter) so I disassembled it, relocated the code to execute from a higher address and added a horizontally scrolling graphics block on it to make it look nicer.

The second time was while playing around on Macintosh Plus with a shareware program, the software was fully functional except that the printouts had a banner that said "DEMO" as a header. Despite being an end user machine, the Old Macs had a very geeky add on. A physical switch that when pressed it would call a debugger (appropriately called MacsBug) So with a Motorola 68000 assembler book on one hand and the other one pressing the "programmer's switch" at the appropriate time I found where the code would branch to print the banner, and put a NOP instruction in the appropriate place and get rid of the annoying banner. That day I understood how people who broke copy protection stuff and hacked around did things. If someone with limited exposure to low level stuff could do it. Imagine what could someone with a little more experience (and patience in using the brute-force approach ) could do They wouldn't have enough knowledge to actually write useful stuff in a low level language, but could break copy protection schemes.

So yeah, I can recognize assembler when I see it, just can't write it

[FZR1KG]

Well, tried redoing the project in Visual Studio 2013

got this crap:

Solution and projects
Solution
Message
industrial_tabbed.sln: Visual Studio needs to make non-functional changes to this project in order to enable the project to open in Visual Studio 2013, Visual Studio 2012, and Visual Studio 2010 SP1 without impacting project behavior.
industrial_tabbed.sln: File successfully backed up as C:\ZLJ_Designer\ZLJ_Designer_source\Backup\industrial_tabbed.sln
industrial_tabbed.v12.suo: File successfully backed up as C:\ZLJ_Designer\ZLJ_Designer_source\Backup\industrial_tabbed.v12.suo
industrial_tabbed.sln: Solution migrated successfully
Hide 3 additional messages
ZLJ_Designer
Message
Show 32 additional messages

The other messages are to say it successfully converted.
So it tells me it's made "non functional" changes, but doesn't tell me what they are.
The code compiles.
Visual studio crashes while trying to run the code in the debugger.
I've reinstalled Visual studio because it says, to repair the install via add/remove programs.
wow
Ok.
Still says MSVSMON.EXE failed to start.
Please repair installation.
Whatever.

[Sigma_Orionis]

Bizarre, that executable is supposedly for remote debugging

Let me guess it's Visual Whatever 2013 Express right?

Not that it matters, it's supported on Windows 8.1

I presume to told the damn POS to debug on the local machine right?

[FZR1KG]

There is no local debug setting on 2013 that I can find.
It sure doesn't look like what you linked to.

The problem turned out to be the any CPU setting in the project/build/general settings.
I had to set it to 0x86
No idea why it comes as any cpu as a default then compiles and won't run or tell you why but, that's what it was.
The rest of my day was taken up trying to get a Prolific USB to RS232 converter working on 8.1
Naturally Prolific says they no longer support it, so go buy one of our new converters.
Fuck that.
The work around is to roll back the driver to the one that came before 8.1 but Prolific doesn't have it on their site. nice eh?
So I found someone that zipped the required files and put it online.
Suddenly their non supported device works on 8.1
Assholes.

I also had to remove some of the fancy stuff from my software because it doesn't support DirectX the same way as it used to.
So now I have to find out what I need to change as I know they still do DirectX support, but the libraries are different.

Still, I can now develop on one PC instead of two which was driving me nuts.
I have a small desk and two laptops, one 3D printer and my project all on it don't really go well.

[Sigma_Orionis]

Prolific, ah yes remember those dudes, most of the noname USB adapter brands use their chipset.

And M$ is tweaking DirectX as well. not surprised things don't work as expected I think they're up to DirectX 11.2 on Windows 8.1

[FZR1KG]

This is why my life is so fucking difficult lately and I stay u till the early hours of the morning:

Code: Select all

(0154) //********************************************************************************************************
(0155) void write_debug(unsigned int BLOCK)
(0156) {
_write_debug:
  BLOCK                --> X-5
    3066: 10       PUSH  X
    3067: 4F       MOV   X,SP
(0157) 
(0158)    apd_reply_ram(&BLOCK, 2);
    3068: 50 02    MOV   A,0x2
(0159)
(0160)    
(0161) }
(0162)
(0163)
(0164)
(0165)
FILE: .\height.asm                      (0001)
                                        (0002) include   "m8c.inc"
307D: 3C A5 5A CMP   [0xA5],0x5A        (0003) include   "map_raw_in.inc"
3080: B0 05    JNZ   0x3086             (0004) include   "macro.inc"
3082: 7C 27 03 LCALL debug_pulse        (0005)
3085: 40       NOP                      (0006)


Notice line (158)
There is a function call there that is meant to, you know, call the function.
Looks like what it does is load the accumulator then just falls through to code in another file.

The question is whether it's the list file generation or the compiler that's faulty.
Either way, shit like this makes it near impossible to debug.

[FZR1KG]

To make matters more fun, Visual C++ 2013 find in files is faulty.
It can't even find some variables that I know are there.
So now I load the files in notepad if I have to do a search for something.
Great eh?

[Cyborg Girl]

Maybe grep is your friend?

http://stefanstools.sourceforge.net/grepWin.html

[Sigma_Orionis]

To make matters more fun, Visual C++ 2013 find in files is faulty.
It can't even find some variables that I know are there.
So now I load the files in notepad if I have to do a search for something.
Great eh?

As crummy as WIndows is , I think Visual what-his-name is worse.

Next life? do yerself a favor, use mingw.

[Cyborg Girl]

I've seen it said that VC++ is a better optimizing compiler (and a better compiler in general), not sure if that holds true for recent versions of GCC though. But I would guess MinGW is inadvisable for working in pure MS Windows environments in any case. Using different compilers together can sometimes do funny things.

[FZR1KG]

Maybe grep is your friend?

http://stefanstools.sourceforge.net/grepWin.html

Too many other things to do to add another layer in.
I will look into it later though.

[Cyborg Girl]

Okay. Command line version of grep would probably be easier and more applicable here, but I don't know a good one for Windows that won't drag in MSys/Cygwin/Perl/etc.

Edit: also one has to know a bit about regular expressions. That's not hard to pick up though. (Mastering them OTOH is a fairly brain-bending exercise.)

[Sigma_Orionis]

I've seen it said that VC++ is a better optimizing compiler (and a better compiler in general), not sure if that holds true for recent versions of GCC though. But I would guess MinGW is inadvisable for working in pure MS Windows environments in any case. Using different compilers together can sometimes do funny things.

AFAIK MinGW works fine in pure Windows Environments, There are even IDEs using MinGW as a back end and they don't require installing MSYS

Okay. Command line version of grep would probably be easier and more applicable here, but I don't know a good one for Windows that won't drag in MSys/Cygwin/Perl/etc.

Well I do.

[Cyborg Girl]

I know MinGW is okay for developing (userspace) Win32 applications. I could swear I've seen stuff about struct alignment incompatibilities between GCC and LLVM/Clang, though, and bad things happening when using different compilers for libraries and programs depending on them? Hmm. Maybe that's just a problem unique to Clang.

Edit: it looks like this may be BS, or some weird issue with Clang. Still not sure I'd use MinGW for driver development though. :/

[FZR1KG]

Well fuck.
It looks like there is some underlying issue with the hardware or compiler.
I can recompile with different libraries that are not in any way used in the functions that are failing, the SP is the same and the mere act of re-compiling causes different faults.
Last time I saw this was a memory boundary issue on 256 byte pages with some instructions.
Typically I was the one to discover this about 12 years ago.
Now it looks like I've found some new issue.
Just have to work out what the fuck it is.
But when code does a simple check like:
if ((ROM_ADDRESS & 0x02) ==1)
and then executes the same code even though you just changed the contents of ROM_ADDRESS from 0x00 to 0xff, there is a serious problem in the system.

[FZR1KG]

More shit.
The compiler offers compilation in the SMM or the LMM by enabling/disabling paging.
It's a compiler setting in the project, as in: project->settings->compiler: enable paging
Paging disabled = SMM
Paging Enabled = LMM

Here's the bad part.
The project works in the SMM fine.
But, if I enable the paging mode it fails and then even disabling paging causes the code to fail going back to the SMM.

IOW, the compiler/environment has made permanent changes to some file once compiled in the LMM.
Also, the boot file (Cypress) generated via boot.tpl (template) causes the SMM to fail if I update from the old boot.tpl to the new.
All it does is provide the start sequence then transfers control to the user program.
After that it is never used so it should not affect my code at all.
Mind you, everything works until the Flash write routines are called and then it resets the CPU.

So I emailed Cypress, attached the project, described the issues and requested a loaner ICE.
I am as of a few hours ago officially not debugging my code anymore.
I am now debugging Cypress issues as it's at their end and I can't even do that till I have an ICE.
And, the customer is screaming...

[Sigma_Orionis]

Damn, that sure sucks moose.

[FZR1KG]

Thankfully because I was one of the first developers on the PSoC, as in before the actual release date of the PSoC, and I still have some contacts there, I was able to secure the loaner ICE.
Hopefully this will help sort the problem out ASAP.